Follow up to #78688

Currently the diagnostics we are reporting are only on build, which means the file needs to be saved first. @DamianEdwards observed that particularly when auto-save is off, there are clunky diagnostics in the editor, which can linger even when they are no longer meaningful:

What we really want is for these diagnostics to be live, and to be reported based on the latest contents of the buffer in-memory. An analyzer might be the best way to do this, though, I think we had reasons when we first implemented this to avoid doing that.

This is also bottlenecked by run-api currently taking path to .cs file, which means the content we want to report any diagnostics about needs to be save to disk.

I believe we had a plan to "relocate" the functionality provided by run-api, possibly to a source package in SDK repo, exposing APIs to obtain virtual project and/or directive diagnostics. We were inclined to do this in such a way that we assume that latest VS Code extension is being used in combination with latest SDK. Do not bend over backwards trying to support old SDKs with new extensions or vice-versa--that contortion was part of why we had first broken run-api out as a separate process. That is my best recollection of conversations with @jaredpar from a while back.

I think we are also facing a question of: since roslyn flows into SDK, is it possible for SDK to flow a source-only package into roslyn, i.e. introducing a cycle in the product construction. I am pretty sure this is something we can do, but, would like to consult with folks who understand VMR stuff better.

@jjonescz, @jasonmalinowski for visibility