This service tries to watch analyzer files to see if they've changed,
and if they have inform the user that they'll have to restart Visual
Studio. It did this via two ways:

1. When a file was first added, it's modification time was stored in
   a dictionary, which was checked in any subsequent entry.
2. Via file watchers.

The first approach was broken in an interesting way: each time a
reference was added, we'd add the modification time to the map (doing
the IO to get the time). This overwrote the previous value, even if
the value had changed in the middle. Then, we'd do the IO a second
time, checking against the value we had just stored. As a result, the
window where we could detect a change in the first approach was very
tiny.

I attempt to rectify what seems to be the intent here and also speed it
up. First off, we won't overwrite previous values so the first approach
has a better chance of actually working. Also, we'll read the data
once instead of twice. Further more, once the file watcher (second
approach) is active, we'll just stop reading timesetamps entirely,
because by then there's no reason to use the first approach at all.

Note this approach still has a flaw: if the file is modified between
when we do any timestamp checking, and the file watcher is active,
we'll completely miss the change and report nothing, at least until
somebody tries adding the analyzer again. This isn't new; it seems
this was already broken anyways. We could just always force the file
watcher immediately, but that might be tied up if somebody else is using
the service so we're still assuming IO is cheaper in that case.

Previously we only trapped some exceptions from the VS file change
service, letting the rest propagate. It turns out this doesn't work
terribly well: if there is an exception, the Lazy<> we did the
subscription with will still hold onto the exception, any use of the
Lazy then rethrows. This means StopFileChangeListening/Dispose never
actually clear the underlying cookie, and we crash in our Finalizer
assert later.

FileChangeTracker is subject to the evils of the file system, and
thus we swallow a few top-hitting exceptions that we shouldn't be
crashing on. For FileNotFoundException, we'll still log a non-fatal
telemetry event so we can continue to drive some fixes into the core
VS service.

We were creating a bunch of tasks on the thread pool, all of which
ultimately contended on the single lock that exists inside of the
current implementation of IVsFileChangeEx. That's silly, so let's just
only try to do one of the background subscriptions at a time.

* Report non-fatal watson instead of crashing VS for failure to UnadviseFileChange in FileChangeTracker.StopFileChangeListening

Fixes https://github.com/dotnet/roslyn/issues/12819

* Address PR feedback and still crash on non-zero return code

* Add VSO bug number as comment for the workaround

Revert "Revert "Disable diagnostic service for projects that we know we don't have all information to provide good results.""

Revert "Disable diagnostic service for projects that we know we don't have all information to provide good results."

this should make roslyn to turn off full project diagnostics when intellisense build is failed for the project.

when we detect intellisense build failure, VS should put actionable data in error list detail pane.
also bing search for the issue should work as well if one prefer blogs.

this change also fix some issue on cross language p2p references. before there was case where we fail to connect cross language p2p reference causing a lot of errors.

this change also include bulk diagnostic update events improvement. this should let us to deal better (especially when we clean those up) when there are a lot of diagnostics.