Keep pipeline of "active" documents, and their JS runtime alive

[gterzian]

The spec has a nice example of how a document of a subframe belonging to an iframe can go from fully-active to just active, while a script could still keep a reference to the iframe.

Currently, an "active" pipeline is closed, both in constellation and script.

The problem with this setup, besides the fact that script can still hold a reference to the document, which can result in crashes on layout(see #22507), is also that per the spec we should actually keep the tasks enqueued for the document, and run them if it becomes fully-active again(something being addressed at #22792).

There are bunch of different places where this matters, here are a few examples:

1. Storage events. Script doesn't propagate storage events to "closed pipelines", see

   servo/components/script/script_thread.rs

   Line 2551 in 481662d

   None => return warn!("Storage event sent to closed pipeline {}.", pipeline_id),

   . The problem is here is for "active" documents, the pipeline is already closed, while per the spec we should actually propagate the events if and when the "active" documents becomes "fully-active".
2. All events are cancelled as as part of clear_js_runtime when a pipeline is closed. Again, those should not be cancelled if the document is still active, since the tasks might still run at a later time.
3. Session history. Since the pipeline is removed from the constellation, this prevents the now "active" document from becoming "fully-active" if it's parent were to go back in history. cc @cbrewster
4. When a window clears its JS runtime, it sets it's state to Zombie. The document checks this before firing load events.

And I'm sure a ton of other things. So these are probably correct, and the problem is that "active" pipelines are closed. Not closing pipelines of "active" documents will take a bit of work across script and constellation.

Also, note that we can remove these from the session history to free resources, however that would require keeping some data to use to create a replacement if necessary(I guess queued tasks would need to be run on the replacement, for example).

Each entry, when first created, has a Document. However, when a Document is not active, it's possible for it to be discarded to free resources. The URL and other data in a session history entry is then used to bring a new Document into being to take the place of the original, in case the user agent finds itself having to reactivate that Document. https://html.spec.whatwg.org/multipage/history.html#the-session-history-of-browsing-contexts