Since ImmutableDictionary and ImmutableSortedDictionary are both
implemented via trees; you can think of an ImmutableDictionary as just
being a sorted dictionary where the underlying key is the hash int.
Since our hash is just a hash of a GUID, we can compare by the GUID,
switch to a ImmutableSortedDictionary, and then avoid another sort
when we're computing checksums.

We previously were using ImmutableArrays, so if you had a large number
of documents (say thousands) we'd be creating huge numbers of huge
arrays over and over again. For this pattern, ImmutableList is more
appropriate.

Use frozen-partial semantics when producing 'accurate' tags.  That way we won't block users as much when copying code.

If we're going to require it, let's at least crash with a useful
exception instead of a null ref.

Fixes #20599

CompilationTracker.HasSuccessfullyLoadedAsync had a same bug with 60cceb9f

https://github.com/dotnet/roslyn/pull/19620#discussion_r117289958

we found 2 issues. 1. hard to validate persisted data and 2. recalculating checksum is faster than reading from storage.

exposing workspace directly cause people to depends on data/service analyzer is not supposed to depend on, also, it sometime access mutable data instead of snapshot of it which analyzer is not supposed to use.

this cut the connection, and expose specific info analyzer is allowed to use in IDE case.