Keep dynamic requires synchronous in module

[bpstrngr]

meta/sanitize currently converts dynamic requires to awaited dynamic imports,
along with making their corresponding enclosing functions async.
This was a tradeoff to support conditional dependency (if(true)require()) instead of all being hoisted as a static import to keep them synchronous.

Synchronous internal or peer dependant calls to the resulting asynchronized functions can be edited to be async as well, but this can get complex beyond simple library initializations, in eg. opaque object hierarchies.

Such peers, relying extensively on commonjs's synchronous loading of what are supposed to be modules, may deserve to be deprecated.

[bpstrngr]

commit 8071336 has modified the behavior to always hoist static imports from requires, unless the block in commonjs is already async.
This promotes editing internal/peer dependent invocations to be asynchronous along with the corresponding commonjs blocks containing the conditional or circular requires when they need to be kept dynamic.
Especially circular requires typically require extensive and necessary edits to be made asynchronous (given eg. a cycle of top-level, static requires - see for example the source definition of rrweb's CSSOM), so an unsupervised general solution is hardly worth it if even possible.

[bpstrngr]

in addition to circular and conditional requires, the case of optional requires has been handled in commit 46841c3.
Requires made in try-catch blocks inside the synchronous scope of the module can be treated as dynamic imports along with those embedded in asynchronous functions, due to top-level await capability in modules.
The same could potentially be implemented for conditional requires in synchronous scopes.