Move ESM loaders off-thread

[JakobJingleheimer]

Resolves #43658

To-dos:

• Address Module serialisation issue (Proxies aren’t serialisable)
• Spawn hooks worker only when custom hooks are supplied
• Convert ESM defaultResolve to synchronous (no real change there)
• Convert import.meta.resolve() to synchronous
  • When no custom hooks are supplied, just regular sync
  • When any custom hooks are supplied, leverage worker + atomics to simulate sync
• Handle very large request/response payload (main ↔︎ worker)

---

Notable changes:

Custom ESM loader hooks run on dedicated thread

ESM hooks supplied via loaders (--experimental-loader=./foo.mjs) now run in a dedicated thread, isolated from the main thread. This provides a separate scope for loaders and ensures no cross-contamination between loaders and application code. A few things to know:

• Communication between application code and loaders code must now be done via the globalPreload hook’s port. Global variables are not shared between scopes.
• The dedicated worker thread is spun up only when at least one custom loader is provided.
• There is an overhead cost to spinning up this thread, increasing both startup time and memory consumption. These are non-trivial, but likely not burdensome.

Synchronous import.meta.resolve()

In alignment with browser behavior, this function now returns synchronously. Despite this, user loader resolve hooks can still be defined as async functions (or as sync functions, if the author prefers). Even when there are async resolve hooks loaded, import.meta.resolve will still return synchronously for application code.

Contributed by Anna Henningsen, Antoine du Hamel, Geoffrey Booth, Guy Bedford, Jacob Smith, and Michaël Zasso in #44710