Investigate making the binding phase lazy

Today, any semantic or language service operations **must** be preceded by a phase of our compiler called binding. This phase does two things: * creates symbol tables as well as symbols per scope * sets parent pointers (because it's already walking the tree anyhow) However, this can end up being a of unnecessary up-front work. For type-checking a given file, the only files that need to be bound are * files that affect global namespaces (e.g. global files or files containing module augmentations, global augmentations, and UMD namespaces) * any file that needs to be checked to check the current file Recently, I spent a bit of time on a plane ride wondering if we could do less work based on this. Instead of forcing all files to be bound, we could bind only global-affecting files up-front, and then force a bind prior to checking or resolving a given file. This has the advantage that something like quick info only needs to bind the minimal set of dependencies before coming back with an answer, making checking significantly lazier. It also means that `skipLibCheck` could end up working faster in command-line scenarios by binding fewer `.d.ts` files that are automatically included (e.g. why bind `.d.ts` files for Jest if you're compiling app code instead of test code?). The flip side of this is that making this lazy can complicate a lot of other operations. Many language service operations don't actually care about binding, but they do care about parent pointers being set. They'll be preceded by a call to `getTypeChecker()` just to ensure files are bound before performing specific steps. > Yeah, I know, weird design! The other issue is that certain type-checker APIs likely need to be guarded against to ensure a requested file is bound. I haven't dived deep here, so this is more of a speculative concern. Finally, while laziness means that we can partially amortize each operation into incremental chunks of work, there's no telling when pulling on a thread of work will trigge…