Missing import trace from error stack when loading a module throws an error

### Version v16.16.0 ### Platform Linux 5.4.0-139-generic #<!-- -->156-Ubuntu SM x86_64 GNU/Linux ### Subsystem modules ### What steps will reproduce the bug? Consider: ```js // foo.mjs import './bar.mjs'; ``` ```js // bar.mjs throw new Error('bar failed'); ``` Run `node foo.mjs`. ### How often does it reproduce? Is there a required condition? Always. ### What is the expected behavior? The stack trace from the error should include a reference to `foo.mjs` line 1 showing where bar was imported from. ### What do you see instead? ```console file:///.../bar.mjs:1 throw new Error('bar failed'); ^ Error: bar failed at file:///.../bar.mjs:1:7 at ModuleJob.run (node:internal/modules/esm/module_job:198:25) at async Promise.all (index 0) at async ESMLoader.import (node:internal/modules/esm/loader:385:24) at async loadESM (node:internal/process/esm_loader:88:5) at async handleMainPromise (node:internal/modules/run_main:61:12) ``` Note that the stack trace does not mention `foo` anywhere. This is not helpful, especially if the error is specifically about how and when `bar` is imported. For example, it might be a singleton and you're mistakenly creating a duplicate by loading it from both `import` and `require`, or it might need something else to be set up on the global first and you're loading it in the wrong order. The above stack is from node 16. Node 18 produces a shorter but similarly lacking stack: ```console file:///.../bar.mjs:1 throw new Error('bar failed'); ^ Error: bar failed at file:///.../bar.mjs:1:7 at ModuleJob.run (node:internal/modules/esm/module_job:194:25) ``` ### Additional information I am aware that `import()` and top-level await complicates this, since modules may be effectively loading in parallel (asynchronously behind the scenes). However, it is **absolutely essential** that this information is made available somehow. If the output ends up being a list of all modules trying to load the offending module then gr…