Fix crash in nuget code when nuget.config file is broken.

report more data on crash due to dispose

Fix crash with fsharp project references

this is port of https://github.com/dotnet/roslyn/pull/20968 to dev15.3.x

If you had a F# project opened with the new project system, it'd supply
an output directory which other projects (like C#) could reference.
If you had a C# project that referenced the F# project, any attempt
to get the C# compilation would crash because we can't actually produce
F# compilations. The fix is simple: don't convert from metadata
references.

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

Other components should be able to access this too, especially since
the workspace itself isn't always there.

Bump the version to 2.3.2

Handle serializing unresolved analyzer references

Add a workaround for P2P references with reference assemblies

Disable NETCore version check

Works around https://github.com/dotnet/roslyn/issues/20945

Ensure we disconnect any projection buffers we create for views

Add null check in ExplicitInterfaceTypeCompletionProvider for invalid code

code

Also ensure filewatcher subscriptions for unresolved analyzers

Be more resilient to external errors when trying to create our underlying persistent storage

Fix a null ref in symbol tree info.

Bump the version number to 2.3.1

Ensure we clean up RuleSetFiles when we close the solution

If you create an elision buffer, there's no way to disconnect the
elision buffer from the underlying buffer once you're done with it,
causing the elision buffer to leak. It's possible to disconnect
projection buffers, so we use them to work around this limitation.

When we create a projection buffer, that buffer is strongly held by
the underlying buffer, which means we have a memory leak unless we
disconnect it by unmapping all spans. This also causes problems because
bugs in the editor around projections can then cause crashes when we
didn't actually need the buffers anymore.

See #20412

The VisualStudioRuleSetManager is a singleton that acts as a cache
of RuleSetFiles and also manages the lifetime of file watching. We
never cleaned that up when we shut down VS, so we leaked a bunch of
file watchers, which would throw during finalization asserting they
weren't cleaned up and bring down the process with it.