Audit "active document" checks #3812

Most places in the spec that want to disallow "bad documents" from doing things check if the document is fully active.

A few places seem to check whether the document is active. I'm unsure whether this is ever a good idea:

• Fully active is the more restrictive check. Being more restrictive is generally a good idea in these scenarios.
• The way the terms are defined, it seems like they're expected to be used with "X is fully active" being a boolean predicate, and "X's active document" being a way of navigating through the spec-object graph. "X is an active document" does not fit super-well with the definitions.

I am not sure I have exhaustively found all such "active document" checks. But, I Ctrl+Fed for "is an active document" and "is not an active document", and found the following:

• Aborting a document load: not interoperable, per "abort" Event Isn't Fired When Aborting Document Load #3525.
• img.decode(): this was recently introduced, and may have been a mistake
• document.open() + document.write(): not interoperable, per Extend document.open/write to non-active documents #2827.
• document.open() alias for window.open(): unsure what's going on here, but maybe carry-over from its proximity to document.open()/document.write() in the spec. Needs interop testing.

A plausible path forward here, that I would prefer, is:

• Fix the interop issues for aborting and document.open()/document.write(), which will result in removing these "active document" checks
• Change img.decode() to test fully active, not just active
• Change the document.open()-alias-for-window.open() case either to remove the check, or strengthen it to fully active, depending on the results of interop testing.

This plan may fall apart if my Ctrl+F was incomplete, and I've misunderstood the scope of the problem.

/cc @bzbarsky @annevk as people with lots of knowledge about this area.