When normal resolution fails to find node types, resolve to globally installed (or bundled?) @types/node as a fallback

When using implicit tsconfig, detect presence of @types/node either locally or globally, and reference "node" types automatically.

Use-case is scripts like this which want to rely totally on globally-installed ts-node:

#!/usr/bin/env ts-node
// do stuff using node APIs; should typecheck
process.env['foo']

Use-cases

• .ts script with shebang and no tsconfig
  • import {readFileSync} from 'fs'; should pass typechecking without any ceremony
  • should import all discovered node_modules/@types? Is slower but a more automatic default
• .ts script with tsconfig.json
  • we should match the way tsserver, tsc, and language service behave. We can resolve node to our local copy if it's not found elsewhere, but we should not otherwise affect behavior. If someone says "types": [] then we respect that
• .ts script with tsconfig.json that extends ts-node/node14/tsconfig.json
  • this implies ts-node is installed locally, and our node peerDep is installed, meaning the user will get node typings. They can specify their own types array, too, and it will behave.

Implementation notes

Ideally we would override ts.getAutomaticTypeDirectiveNames to add node to the array. However, this function is not exposed for overriding on any *Host interface

TODOs

• add "node" to the re-exported @tsconfig/bases lib arrays
  • add tests that our lib array matches the @tsconfig/bases array
  • rethink this; will break automatic parsing of other @types in the local directory? No because when you have a local directory anyway, you can easily create a tsconfig.json
• Declare "@types/node": "*" as a peerDependency to be automatically installed? Same as typescript; ensures npm install -g works out-of-the-box