Fix error cases of <script type=module>

[domenic]

There are several different ways things can go wrong with
<script type=module>. In order from earliest to latest, for a single
module script, they are:

• Fetching failures
• Parsing failures
• Invalid module specifiers
• Instantiation failures
• Evaluation failures

This tweaks the way that these errors interact, to ensure that fetching
failures are treated one way, causing the <script>'s "error" event to
fire, and the other failures are uniformly treated as errors running the
script, causing the global's "error" event to fire (and still firing the <script>'s "load" event).

Fixes #2567.

---

I have a separate document that walks through 7 scenarios both for a module and for its dependent, and shows that they give the expected results.

Tests at https://codereview.chromium.org/2845983002

---

Preview of this, #2604, and #2625 together at https://dl.dropboxusercontent.com/u/20140634/modules-all-better/index.html

/cc @whatwg/modules

[domenic]

Upon reviewing outstanding emails it seems there is another case I have not really taken care of here, which is this:

• A depends on B, C, D
• B and C are already in the map, as errored module scripts (not null)
• We would like the spec to not require fetching/waiting for D

However with both the current spec and the current draft in this PR, waiting for D is required, because you are only allowed to abort "fetch the descendants of a module script" early if you get back null, not if you get back an errored module script.

This should be a pretty simple fix.

[domenic]

I've updated this to also store evaluation errors, so they are treated more uniformly. See tc39/ecma262#862 (comment). I will also update the doc.

[domenic]

Further discussion with @GeorgNeis: this fix for storing evaluation errors is not great. It stores evaluation errors the same as it stores instantiation errors, so they prevent all future evaluation. Whereas intuitively, I think it would be better if stored evaluation errors "made the import statement throw", but still executed code before that point. (However: since import statements are hoisted, the only "code before that point" that could possibly matter is other import statements.) Example:

(This example has been edited to be actually correct; please disregard any earlier version you got in your email.)

// top.js
import "./dep.js";

// dep.js
import "./throws.js";

// dep2.js
console.log("dep2.js");

// top2.js
import "./dep2.js";
import "./throws.js";

// throws.js
throw new Error("boo");

<script type=module src=top.js></script>
<script type=module src=top2.js></script>

Expected:

<exception thrown: boo>

dep2.js
<exception thrown: boo>

Actual:

<exception thrown: boo>

<exception thrown: boo>

That is, top2.js never even evaluates, and thus neither does dep2.js, whereas we'd expect it to evaluate, and then (figuratively at least) have import "./throws.js" re-throw the error.

I'm not sure how to accomplish these semantics without surgery to ECMAScript, having it remember and re-throw the error as discussed in tc39/ecma262#862.

I think for now we should continue to land this PR and tests stemming from it, but note this as a potential future improvement.

[GeorgNeis]

rubberstamp lgtm to unblock larger revisions