[WIP] Migrate hasPendingActivity from ActiveDOMObject to ScriptWrappable.

Source/core/dom/ContextLifecycleNotifier.cpp

Index: Source/core/dom/ContextLifecycleNotifier.cpp
diff --git a/Source/core/dom/ContextLifecycleNotifier.cpp b/Source/core/dom/ContextLifecycleNotifier.cpp
index 7ce7a1e25bbee4d0b8d054840842f8dc41271571..5c76f5bb18ed037fc0a08d58ebf37724e00ad3a7 100644
--- a/Source/core/dom/ContextLifecycleNotifier.cpp
+++ b/Source/core/dom/ContextLifecycleNotifier.cpp
@@ -107,6 +107,7 @@ unsigned ContextLifecycleNotifier::activeDOMObjectCount() const
 
 bool ContextLifecycleNotifier::hasPendingActivity() const
 {
+    // Any idea on how to handle this usage of ActiveDOMObject::hasPendingActivity?

[haraken, 2015/05/15 12:14:25]

It seems that ContextLifecycleNotifier::hasPendingActivity() is used only for
counting the number of pending activities in a worker thread (for some purpose I
don't fully understand).

- If we can remove it, it would be the best.

- If we cannot remove it, I think we can move the logic to
WorkerScriptController (or something like that). Since we're just interested in
the number of pending activities of the worker thread, we can manage the number
per isolate (i.e., we don't need to manage the number per context).

Maybe kinuko-san has an idea on this.

[kinuko, 2015/05/19 16:02:30]

My old memory tells me that this code is (was?) used to keep a parent execution
context (i.e. Document) alive while any of its child DOM objects have pending
async operations.  I'm a bit unfamiliar with the background concept of the
'document lifetime', how do we do so for Document today?  Worker's basically
trying to do same as Document does (but doing so across threads as worker's
execution context and worker's DOM object live on different threads), if we
don't need this for document we can probably remove it for worker too.

     for (ContextLifecycleObserver* observer : m_observers) {
         if (observer->observerType() != ContextLifecycleObserver::ActiveDOMObjectType)
             continue;