Don't handle impossible errors in HostResolveImportedModule

Several of the cases that were handled as errors are actually impossible
to hit. Instead of throwing errors in these impossible situations, we
can just assert that they are impossible.

This also cleans up "resolve a module specifier" and the module map to
be clear that they operate on URL records, not on absolute URL strings.

Note that the remaining error case, of a null result in the module map,
may go away, depending on how we fix #2629 and #2630. It currently
occurs because of our strategy of calling
ModuleDeclarationInstantiation() even when we know it will fail, in
order to propagate errors, but that strategy is seeming increasingly
unwise in the face of those bugs.

Author: domenic

source

@@ -87197,7 +87197,7 @@ interface <dfn>NavigatorOnLine</dfn> {
      a module specifier</span> given <var>module script</var> and <var>requested</var>.</p></li>
 
      <li>
-      <p>If the result is error:</p>
+      <p>If <var>url</var> is failure:</p>
 
       <ol>
        <li><p>Let <var>error</var> be a new <code>TypeError</code> exception.</p></li>
@@ -88283,8 +88283,8 @@ document.querySelector("button").addEventListener("click", bound);
   scripts</span> versus <span data-x="module script">module scripts</span>, since both of them use
   the <code>script</code> element.</p>
 
-  <p>A <dfn>module map</dfn> is a <span data-x="ordered map">map</span> of <span data-x="absolute
-  URL">absolute URLs</span> to values that are either a <span>module script</span>, null (used to
+  <p>A <dfn>module map</dfn> is a <span data-x="ordered map">map</span> of <span data-x="URL
+  record">URL records</span> to values that are either a <span>module script</span>, null (used to
   represent failed fetches), or a placeholder value "<code data-x="">fetching</code>". <span
   data-x="module map">Module maps</span> are used to ensure that imported JavaScript modules are
   only fetched, parsed, and evaluated once per <code>Document</code> or <a
@@ -88321,8 +88321,8 @@ import "https://example.com/foo/../module2.js";</pre>
   </div>
 
   <p>To <dfn>resolve a module specifier</dfn> given a <span>module script</span> <var>script</var>
-  and a string <var>specifier</var>, perform the following steps. It will return either an
-  <span>absolute URL</span> or failure.</p>
+  and a string <var>specifier</var>, perform the following steps. It will return either a <span>URL
+  record</span> or failure.</p>
 
   <ol>
    <li><p>Apply the <span>URL parser</span> to <var>specifier</var>. If the result is not failure,
@@ -88410,14 +88410,39 @@ import "https://example.com/foo/../module2.js";</pre>
    object</span>'s <span data-x="concept-settings-object-module-map">module map</span>.</p></li>
 
    <li><p>Let <var>url</var> be the result of <span data-x="resolve a module specifier">resolving a
-   module specifier</span> given <var>referencing module script</var> and <var>specifier</var>. If
-   the result is failure, then throw a <code>TypeError</code> exception and abort these
-   steps.</p></li>
+   module specifier</span> given <var>referencing module script</var> and
+   <var>specifier</var>.</p></li>
 
-   <li><p>Let <var>resolved module script</var> be <var>moduleMap</var>[<var>url</var>]. If no such
-   entry <span data-x="map exists">exists</span>, or if <var>resolved module script</var> is null or
-   "<code data-x="">fetching</code>", then throw a <code>TypeError</code> exception and abort these
-   steps.</p></li>
+   <li><p>Assert: <var>url</var> is never failure, because <span data-x="resolve a module
+   specifier">resolving a module specifier</span> must have been previously successful with these
+   same two arguments during the appropriate invocation of <span>fetch the descendants of and
+   instantiate a module script</span>.</p></li>
+
+   <li><p>Let <var>resolved module script</var> be <var>moduleMap</var>[<var>url</var>]. (This entry
+   must <span data-x="map exists">exist</span> for us to have gotten to this point.)</p></li>
+
+   <li>
+    <p>If <var>resolved module script</var> is null, then throw a <code>TypeError</code>
+    exception and abort these steps.</p>
+
+    <div class="example">
+     <p>This occurs when we have previously tried to <span data-x="fetch a single module
+     script">fetch</span> <var>url</var>, and failed, but are now rediscovering that fact in a new
+     module script graph. For example, given a file <code data-x="">module.js</code> whose contents
+     are</p>
+
+     <pre>import "./404.js";</pre>
+
+     <p>then we could get here as part of <span data-x="fetch a module script graph">fetching the
+     graph</span> for the second <code>script</code> element in the following HTML:</p>
+
+     <pre>&lt;script type="module" src="404.js">&lt;/script>
+&lt;script type="module" src="module.js">&lt;/script></pre>
+    </div>
+   </li>
+
+   <li><p>Assert: <var>resolved module script</var> is a <span>module script</span> (i.e., is not
+   "<code data-x="">fetching</code>").</p></li>
 
    <li><p>If <var>resolved module script</var>'s <span
    data-x="concept-module-script-state">state</span> is "<code data-x="">errored</code>", then throw