In a larger refactoring I had commented some code out in
NodeKeyValidation.AddProject. This meant that when we did a refactor
rename of a CodeElement, we wouldn't end up updating node keys for all
the existing CodeElements out there. The expectation is CodeElements
are still valid. Uncommenting the code and bringing it back inline with
the current design makes everything work again.

Fixes dotnet/roslyn#31735.

We were creating them directly, but this meant that there was no
proper way to enumerate all of them since we weren't providing a
ProjectCodeModelFactory. This brings the tests slightly more inline with
"real" Visual Studio.

Finish the project context implementation for the free-threaded project system shims

Disable a few tests on Mono

This disables a few tests that have recently turned up as flaky on Mono.

- DestructorOverridesNonDestructor: this test is pretty specific to the
JIT / GC implementation. It doesn't run on CoreClr already due to the
subtle differences. Shouldn't have been run on Mono in the first place.
- TestCallMethodsWithLeastCustomModifiers: there appears to be a runtime
race condition around how overloads that differ by only `modopt`
elements are resolved. Follow up issue
https://github.com/mono/mono/issues/12422

This is an optimization that if you have 20 or 30 files open, and only
one of them came from a shared asset project, and that project is
changing context, we don't need to refresh all of the rest. Since the
refreshing is on the UI thread, we want that to be quick.

The protected method took the state lock, got the container, let go
of the state lock, and then acquired all of the locks. This isn't
really safe anyways because once all the locks were released the
document could have been closed and disconnected entirely.

The pattern matches all our other On* methods.

This was being applied at the caller, a few lines before the actual
call. Now it's obvious what it's doing.

This was setting a magic thread local property which tracked if we
were currently unloading a project, and if so avoided taking a lock
when the context changed. This was somewhat self-inflicted because
we were trying to change project contexts in the Visual Studio shell
during the middle of unload. We're not doing that anymore, and removing
this also allows us to allow project removal off the UI thread.

This behavior causes all sorts of problems: removing a file (which
can now happen on a background thread) then tries to call into
all sorts of UI-affinitized APIs which are unavailable there.
Practically,  there's no reason we must do this anyways: if you do
remove a file in one context, we'll update our internal structures to
point to a new context. There's no real harm in that being temporarily
out of sync: either we'll pick the right context at random and the
user won't notice, or if we pick the wrong one, they can select the one
they want and everything will be updated again.

Fixes dotnet/roslyn#31019.

The comment implied that custom handling could be done by overriding
this but no such overriding is being done, and trying to do so would
be very sketchy.

Because the code wasn't finished, we were leaking IVsHierarchies since
we had no cleanup logic. We hold onto the IVsHierarchies per document
cookie (although we do share the watchers), so if we close a file we
only unhook from the correct IVsHierarchies rather than having to re-
look at everything.

We already had this inside of VisualStudioRuleSetManager, and we need
it for more things too. For now all the locking semantics are being
kept identical.

The basic mental here is to determine a context for a file, we start
with the Running Document Table and grab the IVsHierarchy for that file.
We then chase it through shared projects until we arrive at final
IVsHierarchy. This should be the IVsHierarchy we were given for the
project. In the case of multitargeting projects, there's one last hop
where we fetch a VSHPROPID_ActiveIntellisenseProjectContext that just
returns the project name instead of a IVsHierarchy. If you squint you
could imagine that as if it returned the IVsHierarchy for that project
except we don't have unique ones.

To set the context, we start with the project and walk those
IVsHierarchy pointers backwards. At each step we can do an operation to
figure out which IVsHierarchy needs its pointer updated, and we point it
to build the chain, moving back to the IVsHierarchy that will end up
in the Running Document Table.

This is (still) leaking IVsHierarchies that we subscribe to, and that
will be fixed next.

Avoid navigating to message severity items unless requested

Closes #31862.

1. we never disposed tag aggregator leaking all taggers ever created on the buffer involved in contained document

2. we hold on to taggers not related to our buffer but ones that are related to other buffers. for example, our subject buffer is actually subject buffer which involves template C# buffer + html buffer where portion of html buffer are mapped to the subject buffer. that we end up holding on to all html taggers.

Fixes an occasional failure in the ErrorList test.

Fix null check combined with nullable bool test

Pattern-based 'await foreach' should find parameterless 'GetAsyncEnumerator' and 'MoveNextAsync' (#32184)

Fix IDE0055 formatting errors

* Run CI builds for 16.0 preview2 vs-deps PRs

* Trigger branch builds on commit for preview branches

Fixup the triggers

Fixup our triggers for branches.

Publish VSIX installer with build

Change no conversion to idisposable message

Fix parsing regression on switch case expression that is parenthesized unary expression