Fixes #50917, using the solution described in #50917 (comment).

The general algorithm for --experimental-detect-module is to try to parse as CommonJS, and if a syntax error is thrown that corresponds to ESM syntax (import or export, or import.meta), try again as ESM. The edge case pointed out by #50917 is when there’s syntax that throws in CommonJS but parses in ESM, and this syntax is above the first ESM syntax (so top-level await, or a declaration of a variable with the same name as one of the CommonJS module wrapper variables such as const require =, on the first line or any line above the first import or export).

The tricky thing is that the errors thrown by top-level await or const require in CommonJS are the same errors as thrown by typing await in any ordinary sync function, or by declaring require twice in user code (e.g. const require = 1; const require = 2). So we only want to retry parsing as ESM when these errors are because the await or problematic variable declaration is at the top level, where it throws in CommonJS but parses in ESM.

To determine this, this PR creates a new error path where if the CommonJS parse returns a syntax error corresponding to either of these cases, we do a special second CommonJS parse of the code wrapped in an async function. This wrapper function creates a new scope, so const require is no longer a problematic redeclaration; and await no longer throws because it’s within an async function. This wrapper only affects the top level, so await in a sync function farther down or variable redeclarations farther down (or two const declarations at the top level) will still throw; but the code permitted in ESM parses successfully. If this second parse doesn’t throw any errors, we resume the detection algorithm and try parsing as ESM.

@nodejs/loaders @chjj @meyfa @joyeecheung