Rename intenral code to 'FindUsages' so it better reflects that it can present results for more than just FindReferences.

Our references were previously a mix of preview 4 and some build between preview 4 and 5.  That was causing build output double writes.

Fixes part 2 of #9674 for both the general code style page and the
naming style option page.

This also removes the superfluous "EnforcementLevel" class in the
NamingPreferences namespace that was basically a duplication of
"NotificationOption"/"NotificationOptionViewModel" in the general
CodeStyle namespace.

Fixes #12669. Addresses one part of #9674

Fixes both the general code styles page and the naming styles page

Use tuple syntax in the compiler

Create a code fix that offers to add a reference to System.ValueTuple if it is missing and you use a tuple.

* Hookup non-Roslyn view to the document tracking service on a foreground scheduled task.

RPS traces show that we are forcing the text view creation too eagerly on the UI thread during file open. This should very likely fix VSO #[223317](https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=223317&triage=true).

* Explicitly schedule on a foreground task

We were using a Dictionary<..., Guid> which was forcing a JIT during
startup. Replacing it with Tuple<Guid> means we don't take the JIT
since it's a reference type.

These used to be split up into separate assemblies, but aren't anymore.

We were previously realizing the workspace and then reading in all the
FunctionIds to see if we should log each of those. We can do that from
the global option service directory (avoiding having to touch the
Workspace) and also not doing that until we actually need to. In most
cases ETW is off so we shouldn't even be looking at all.

This doesn't need to be initialized on the UI thread at all.

We had a bunch of crashes against Update 3 where
MiscellaneousFilesWorkspace would go sideways when we were responding
to workspace changed events for buffers on a different thread. Commit
dfcfbaa6 mitigated the direct crashes
somewhat, but still meant we had some racy code which we probably
didn't want. This hardens the code so if we do get a notification
on a background thread (which is unfortunately controlled by the
sending workspace), we'll just send it back to the UI thread and safely
handle it from there.

In the dumps in question, even the Roslyn workspace was attached to
the background thread, which is known issue if somebody created it via
MEF when they shouldn't have. That's being fixed as a part of
https://github.com/dotnet/roslyn/pull/14354 so we won't concern
ourselves with it here.

* Ensure that we normalize the CPSProject bin output path even when it is set via the property IWorkspaceProjectContext.BinOutputPath

* Fix unit test

* Make property internal for testing purposes

* Fix expected project file path in the test

don't use double check locking.

This reverts commit 7dd78ae8, reversing
changes made to 449f5586.

Windows Error Reporting is insisting it's surprisingly common for us
to have a thread trying to create a compilation while Visual Studio
is shutting down and we can't make COM calls anymore. This prevents
that from happening. This is a tactical fix and we'll still let the
rest of metadata snapshot system work normally.

Use the resolved references in DPL.  This is necessary because VB adds mscorlib to the set of
resolved references implicitly.

Fixes #14433 and #14584