Add <script type="module"> and module resolution/fetching/evaluation

This adds support for <script type="module"> for loading JavaScript modules, as well as all the infrastructure necessary for resolving, fetching, parsing, and evaluating module graphs rooted at such <script type="module">s.

Some decisions encoded here include:

- Always use the UTF-8 decoder, ignoring the charset="" attribute or the Content-Type header parameter.
- Always use the "cors" fetch mode, and use the crossorigin="" attribute to decide between "omit"/"same-origin"/"include" for the credentials mode.
- Require that the response be served with a JavaScript MIME type for ts Content-Type header.
- Use <script defer>-like semantics by default: do not execute until parsing is finished, and execute in order. The async="" attribute can be used to opt in to an "execute as soon as possible, in any order" semantic. Unlike for classic scripts, in no cases do we block further parsing or script execution until the module tree is finished loading. This applies to both inline and external scripts.
- For module resolution, allow absolute URLs and anything that starts with "./", "../", or "/", with this latter set being interpreted as relative URLs. Everything else (e.g. bare specifiers like "jquery") fails for now. No automatic ".js" is appended.
- Modules are memoized based on their request URL, whereas import specifiers inside the module are resolved based on the module's response URL.

In the course of adding this functionality, large parts of script execution, fetching, and creation were refactored, including moving around some sections and reorganizing others. Conceptually, scripts are now either "classic scripts", "module scripts", or "data blocks". The result should generally be clearer and easier to follow.