File-based program directive error squiggles

[RikkiGibson]

#:property LangVersion preview
#:BAD
Console.Write("Hello, world!");

In the above scenario, we should use the SimpleDiagnostics that come back from run-api to show a red squiggle under BAD, show the error message on hover, etc., just like a normal compiler or analyzer diagnostic.

[RikkiGibson]

A reasonable way to do this might be to add a solution-level analyzer which can request this information and forward it along.

[jasonmalinowski]

And for some of the other failures, maybe we should generally have a workspace diagnostics provider for providing diagnostics from project load issues. Right now we'll dump them into the output window, but we could be a bit smarter there.

[RikkiGibson]

I think I see 2 basic ways of doing this:

1. Take the diagnostics we find in run-api, prior to a design-time build, and stash them somewhere that an analyzer would be able to look them up and report them. (Does this play nicely with the invariants of analyzers, determinism etc.? Any prior art which is similar to this?)
2. Ship an analyzer in .NET SDK which reimplements or shares the checks run-api is doing in order to report equivalent diagnostics.

@jasonmalinowski @jjonescz for thoughts.

(1) reminds me of the "compiler analyzer" which effectively uses an analyzer to wrap/drive the process of obtaining compiler diagnostics. But that does not look up stashed information in a compilation, it just calls the compilation APIs for getting diagnostics. But for us that could involve shelling out to dotnet restore and that does seem bad to do in an analyzer.

(2) seems easier to do correctly.

[jasonmalinowski]

I would imagine we wouldn't implement this with Roslyn analyzers but with one of our other diagnostic abstractions. On the LSP side we have an abstraction around a "diagnostic source" which could be various things, and we can make these special errors be one of those. @dibarbet or @JoeRobich would better know what to recommend in terms of exactly what to implement.