Sync XS interpretation of dynamic module loading

[kriskowal]

XS is implementing dynamic module loading and converging the implementation in our shim. There are a number of rational divergences that we should investigate adopting.

1. loadHook https://github.com/endojs/endo/issues/420
2. What I’ve called the exportsProxy and proxiedExports correspond to moduleNamespaceObject and moduleEnvironmentRecord, the latter being the object that represents the names as seen in the lexical scope of a module, both imported and exported, which the module may manipulate over the course of its initialization, possibly once-only if they bind to a constant, possibly within the confines of temporal-dead-zone semantics. The keys of the module exports namespace and the module environment record may be aliased through as clauses, so they are not the same, even if they correspond to the same values.
3. The third-party-module-record form should be initialize(moduleEnvironmentRecord, meta) instead of execute(proxiedExports, compartment, importSpecifiersToFullSpecifiers). In XS and in the specification proposal, initialize must be synchronous if the module can be initialized synchronously, and must be asynchronous if it employs top-level-await, such that synchronous subgraphs can be initialized in a single event.

Provided we can make all of this work, this should be the basis of our joint proposal to TC39.

[Tartuffo]

@kriskowal Please triage (MN-1 or not).