feat(module-source): Add XS specific variant

[kriskowal]

Closes: #2250
Refs: #2251

Description

Toward using native XS compartments and module sources, this change adds an XS-specific variant of @endo/module-source that patches the native ModuleSource in place instead of entraining Babel. This will allow an XS-specific @endo/import-bundle variant to load both pre-compiled sources (pre-json-mjs) and original ESM sources (mjs).

This change is opt-in, provided the xs runtime condition. These are conditions introduced by Node.js with the node -C development entry.js precedent and supported by @endo/compartment-mapper for both endoScript and endoZipBase64 bundle formats.

Security Considerations

This change increases exposure to a native ModuleSource as implemented in a memory-unsafe language.

Scaling Considerations

We expect a significant improvement in performance at both bundle time and run time upon completion of #2251 since native ModuleSource is considerably faster than a virtualization.

Documentation Considerations

Captured in NEWS.md and README.md.

Testing Considerations

This change introduces a minimal text:xs that runs with xst and is exercised by Continuous Integration. This minimal test can be expanded as we make more progress with the XS-variant of SES, which will allow the virtual Compartment to opt-in to use native ModuleSource.

Compatibility Considerations

The XS-specific shim is not a one-to-one replacement for the Babel implementation and does not support some of the optional arguments. Code that expects these hooks to be called will be dismayed. Despite these limitations, no existing program should break: the xs condition should not be present in any existing application.

Upgrade Considerations

This change will not come to bear on the Agoric chain until after a new version of XS becomes available with a new XS-specific lockdown preamble.