Follow-up from the TypeScript un-fork (#35621).

Today Deno ships a built-in, vendored copy of @types/node inside the binary
and injects it into every type-check program via asset:///lib.node.d.ts
(referenced from lib.deno.shared_globals.d.ts). Because @types/node
declares global ambient types, exactly one copy must be present in a program,
so when a user actually has @types/node installed - directly or transitively

• Deno has to detect that copy and serve it instead of the built-in one to
  avoid duplicate-identifier errors. That detection is what fix(check): load a single @types/node #35641 (direct
  dependency) and fix(check): detect transitive @types/node for the single node types copy #35871 (transitive dependency) implement.

This built-in-plus-detection arrangement is a temporary workaround. The vendored
copy has to be regenerated and kept in sync with upstream DefinitelyTyped
(tools/update_types_node.ts), it bloats the binary, and the "which copy wins"
logic exists only to reconcile the built-in against an installed one.

Proposal: stop vendoring @types/node in the binary. Instead, download the node
types into the global cache (DENO_DIR) at install time - e.g. during deno install - if they are not already cached, and resolve them from there like any
other cached dependency. That gives a single source of truth, a pinned and
updatable version, no built-in-vs-installed reconciliation, and a smaller
binary. The version could track the Node compatibility target Deno reports.

Open questions to work out:

• Exactly when to fetch (first run vs deno install vs lazily on first check),
  and offline / airgapped behavior.
• Which @types/node version to pin and how it relates to Deno's Node compat
  target.
• Interaction with a user-installed @types/node (theirs should still win).
• Whether deno types / the LSP need any changes to point at the cached copy.

Once this lands, the built-in copy and the direct/transitive detection in
cli/tsc/mod.rs (#35641 / #35871) can be removed.