Partial Semantic Editing Operations

# Background We've heard from many TypeScript and JavaScript developers that large codebases suffer from massive startup delays in the editor. This is often due to program construction time. Before any semantic operation can be triggered, TypeScript has to effectively do the following: 1. Find out which project a file belongs to 1. Load that project 1. loop: Read each of the given files 1. Parse the file 1. Look through the imports/exports and resolve each import path 1. If new files were found, add them to the program's file list and go to `loop`. All this is unfortunately synchronous today, and even if it wasn't, this might still end up being a lot of work for larger projects. For users with many files and non-trivial resolution schemes, we've witnessed program construction times that have taken *minutes*. This can be frustrating for lots of users whose first tasks might just include navigation and some basic editing. ## Basic Code Navigation Let's take the following code and assume a user requests to go-to-definition on the `import` statement: ```ts import * as foo from "./foo"; ``` If TypeScript is still loading the program, it can't answer where `./foo` resolves to. But it's a relative path, and for most users this feels like something so obvious and cheap to compute. Most users could guess which file it points to be right. If there was a lightweight way to say "it should probably take you here" until a program is fully loaded up, it might get 99% of the job done for 99% of people. If there was a way to guess 2-3 locations and give the editor a list of locations to look up, that might just solve the issue. ## Basic Completions Let's take the following and assume the user requests completions in each of the comments: ```ts import { SomeClass } from "some-module"; function foo() { function bar() { b/*inBar*/ } function baz() { SomeClass./*afterDot*/ } new /*afterNew*/ } class CurrentClass { /*inClass*/ } ``` Completions at …