Linker: consolidate module injection code

When loading modules for use by the new runtime, the linker has to load modules from text and inject (or maybe reflect?) the API into what's know as a Synthetic Module.

To do this, we have to find the exports of the loaded module. And this gets a bit hairy because of CJS and ESM and I'm not even sure what else.

Here's the code to find the exported values right now:

  let target = exports;
  if (exports.__esModule && target.default.default) {
    // CJS
    target = target.default.default; // ?!
  } else {
    // ESM
    // If we import @openfn/language-common@2.0.0-rc3, its named exports are found on the default object
    // Which doesn't seem quite right?
    // This elaborate workaround may help
    if (
      Object.keys(exports).length === 1 &&
      exports.default &&
      Object.keys(exports.default).length > 0
    ) {
      target = target.default;
    }
  }

I mean it's horrible, full of guesswork, and just needs bringing under control. And to be unit tested effectively.

For what it's worth, given the list of exports, here's how we expose them in the Synthetic Module for use in the runtie:

  const exportNames = Object.keys(target);
  // Wrap up the real module into a Synthetic Module
  const m = new vm.SyntheticModule(
    exportNames,
    function (this: SyntheticModule) {
      for (const e of exportNames) {
        this.setExport(e, target[e]);
      }
    },
    { context }
  );

Start from the linker’s module-loading and export-discovery code described in the issue, then trace how the resulting names and values are passed to vm.SyntheticModule. Define and unit test the expected handling of CJS and ESM export shapes, and consider the work done when the injection logic is consolidated without guesswork.