Add built-in module support to Endo bundler

[kriskowal]

We now have an Endo bundler, which we use to generate SES distribution artifacts instead of Rollup. #175 This allows us to bootstrap SES on Endo. We should also be able to bootstrap Endo.

To do so, we would need to thread the filesystem import into a bundle. This should be a relatively surgical change, adding each of the exit modules to the generated arrays of cells and namespaces in a bundle, and using a CommonJS require to thread it in. This will introduce the question of the compile target for the bundle, which is currently an arbitrary JavaScript program that has no notion of receiving a module system from the environment. We may need to specify that the integration with the parent environment is specifically CommonJS for these exits.

This may also require us to confront differences between Node.js ESM and SES ESM, particularly that Node.js ESM supports import.meta.url, -R ESM supports __dirname and __filename accidentally, and SES ESM does not currently support either. #291 We will likely want to support both in order to provide a bridge.

We know we won when we’re able to use the Endo bundler to generate a single-file Node.js library from the Endo sources that is suitable as an entry point either like -r @endo/esm (as a replacement for -r esm) or as simply endo.

We know we really won when we’re able to use this Endo implementation of ESM instead of Node ESM throughout the Endo repository, for all build and test tooling.

We know we really really won when we can use this to replace -R ESM in Agoric SDK.

[kriskowal]

I can declare victory on replacing -r esm well enough to close out this issue. Endo’s compartment-mapper is also able to leave holes for built-in modules and fill them in when an archive is initialized.

The only part of this story that isn’t complete is automatically connecting platform modules, but that’s not sufficiently motivated anymore. We will open a new issue when we have a more specific motivating use case. One thing that is clear is that Endo is not going to grant Endo Applications direct access to powerful Node.js API’s, certainly not without the LavaMoat policy story being considerably advanced.