[Experiment/Work-in-Progress] Lazy Binding

[DanielRosenwasser]

Experimenting with #35120.

Current issues:

• This is an API-breaking change
• It would be nice if we didn't need to do the top-level walk on files for export as namespace statements.
• Our compiler uses the checker APIs to grab symbols off of arbitrary import nodes and query which files a given file relies on. Maybe we could add explicit way to bind the source file before doing this.
• Our services layer uses the checker APIs on arbitrary nodes for almost every operation. We'll need a similar workaround here.

Ideals/Goals:

• This should ideally improve time to interactivity in certain projects. You should be able to get quick info in a shorter amount of time if most of your source tree is TypeScript modules.
• This should improve instances of --incremental builds with TypeScript when files don't have to be rechecked.
• This could improve bind times for codebases with skipLibCheck where there's accidentally a bunch more code that could be brought in from node_modules/@types.
• We should ensure that find-all-references does not wreck lazy binding. If a file doesn't contain a given search string, we usually shouldn't need to dive into the file.

Things to be mindful of:

• Auto-imports probably wreck lazy binding. If you need global completions, you probably need to bind every module file that's in the current program.
• JavaScript doesn't get lazy binding. That's because we don't know what sorts of TS-recognized patterns a JS file has until we've bound. In fact, we often don't even know if a JS file is a CommonJS module until we've bound that file. We could optimize that a bit here.
• This change would make many operations a field of land-mines. We oftne have crashes on non-existent .symbol properties or .parent properties (because we've declared them as always-present to deceive the type-checker). This can happen way more often on arbitrary nodes that come from unbound files.