[DO NOT MERGE] test: duplicate async_hooks tests in esm

Spinning off from https://github.com/nodejs/node/issues/43408#issuecomment-1203206772 and following comments, in this PR I ported the async_hooks tests in test/async-hooks/*.js into ESM. I left the original CommonJS versions side-by-side with the ESM versions, so the diff shows just 90 new .mjs files; but the tests themselves are unchanged other than require becoming import and similar expected changes related to conversion to ESM (declaring __filename, replacing top-level return with process.exit(), etc.). This PR isn’t meant to be merged, which is why I’ve opened it as a draft; it’s just meant to provide a branch to test issues related to async_hooks and ESM. (Branches off of and includes #44322.)

On my machine, running python tools/test.py -J --mode=release async-hooks for this branch yields 58 failing tests. Arguably there should be no failing tests here; async_hooks should behave identically when used in ESM code as when used in CommonJS code, like most (all?) other Node APIs. So this raises a few questions:

1. Are the failing tests simply tests that need rewriting? The tests are very specific in the assertions they validate, looking for things like the number of both user-created and internal Node async resources created over the lifetime of the Node process. Perhaps the different results are expected, and the tests should simply be changed so that the ESM versions have different expectations to validate; or the validation should become less specific, such as by filtering out all the Node internal async activity somehow.

2. Is something about the ESM loader broken? Is it creating async resources before it should, or not resolving all startup async resources before user code runs, denying async_hooks the clean environment it expects when the first line of user code runs? Is there some change that we can make to the ESM loader to make it behave more similarly to the CommonJS loader, from async_hooks‘s perspective, without that change breaking anything else?

3. Is async_hooks itself somehow broken or incompatible under ESM? And if so, can it be fixed? In the worst case, something like the async activity of import statements themselves would be confusing async_hooks, presenting us with what I assume is no way to make the async_hooks API behave equivalently in ESM; or user code needs to somehow filter out or accommodate all these “module loading” async resources that don’t exist in the sync CommonJS.

cc @nodejs/async_hooks @nodejs/modules @nodejs/loaders