fix(check,lsp): support "moduleResolution": "bundler" and "module": "esnext" in tsconfig

[nathanwhit]

Closes #29673.
Ref #25359.

this adds support initial for "moduleResolution": "bundler".

"bundler" module resolution has two differences compared to "NodeNext":

• enables support for resolving relative paths without extensions (i.e. sloppy imports)
• changes the import conditions used. it disables the "node" import condition, and then
  • if "module" === "esnext" , always resolve with the "import" condition (even for require)
  • if "module" === "preserve", resolve with "import" for imports, "require" for requires

this PR implements the sloppy imports part (which is messy because the initialization order isn't quite right), but doesn't do the import conditions part. that shouldn't be too hard either, the main issue is that it would create a cyclic dependency between the node resolver and the tsconfig resolver, which we'd need to break somehow (potentially using arc_swap or something)

[nayeemrmn]

👍

I'll probably have to restructure the subsystem init sequence to clean this up.

Before:

1. ConfigTree (including WorkspaceResolver)
2. LspResolver (including NodeResolver and CliResolver)
3. CompilerOptionsResolver

After:

1. ConfigTree
2. NodeResolver
3. CompilerOptionsResolver
4. WorkspaceResolver
5. CliResolver