feat: transpile .mts with swc strip-only

[turadg]

Refs: Agoric/agoric-sdk#5760
Refs: #2415

Description

spike on getting Endo to bundle .ts syntax files as .js using swc-project/swc#9138

current status:

❯ yarn test test/mts-imports-cjs-define.test.js

  ✘ [fail]: fixtures-esm-imports-cjs-define / makeArchive / parseArchive / hashArchive consistency Rejected promise returned by test
  ✘ [fail]: fixtures-esm-imports-cjs-define / makeArchive / parseArchive, but with sha512 corruption of a compartment map Rejected promise returned by test
  ✘ [fail]: fixtures-esm-imports-cjs-define / makeArchive / parseArchive Rejected promise returned by test
  ✘ [fail]: fixtures-esm-imports-cjs-define / makeArchive / parseArchive with a prefix Rejected promise returned by test
  ✘ [fail]: fixtures-esm-imports-cjs-define / writeArchive / loadArchive Rejected promise returned by test
  ✘ [fail]: fixtures-esm-imports-cjs-define / writeArchive / importArchive Rejected promise returned by test
  ✔ fixtures-esm-imports-cjs-define / loadLocation
  ✔ fixtures-esm-imports-cjs-define / importLocation

So next steps I think are:

• make a parse-pre-mts.js for import-archive-parsers.js
• make a parse-archive-mts.js for archive-parsers.js

Security Considerations

Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls?

Scaling Considerations

Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated?

Documentation Considerations

Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users?

Testing Considerations

Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet?

Compatibility Considerations

Does this change break any prior usage patterns? Does this change allow usage patterns to evolve?

Upgrade Considerations

What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed?

Include *BREAKING*: in the commit message with migration instructions for any breaking change.

Update NEWS.md for user-facing changes.

Delete guidance from pull request description before merge (including this!)

[erights]

@kriskowal , considering what this modifies, I'm gonna wait for you to do a pass first.