Handle `#:project` directives in the IDE

[RikkiGibson]

Min-bar for #:project: when the associated project has been built, we can at least behave at equivalent quality to <Reference> item in an ordinary project. e.g. go-to-def goes to a "metadata as source" view of the project, rename across projects may not work gracefully, etc. But the IDE is not completely broken.

Ideal quality bar: #:project references are handled similarly to <ProjectReference> items in ordinary projects. Editor features involving the symbols from the other project will use the appropriate source code elements from the other project, etc. This may be tricky, as the Roslyn Workspace usually only wants to resolve project references to source when the projects are in the same workspace. But our design has the projects in different workspaces. The file-based-programs that we load, are not members of any solution, and so it's not obvious how we would load them in the ordinary workspace if we wanted to. So, there are unknowns to investigate in order to budget the engineering work to reach the ideal level of quality here.

[CyrusNajmabadi]

I have many thoughts here. Please keep me in the loop :-)

[CyrusNajmabadi]

A core thing to realize is that we have an internal abstraction model. That abstraction doesn't have to ties directly to use artifacts. For example we have many virtual projects for a single real user project. And a p2p reference is how we represent a compilation depending on another.

So we likely will want an in memory representation that leverages these concepts, to power the experiences. Instead of trying to represent in some other fashion that then everything downstream has to adapt to.

[CyrusNajmabadi]

In other words, you want it to be mostly transparent if these things came from "real projects" or we're virtually stitched together from project-directives.