Add a SetProperty API for CPS to passing msbuild properties

This reverts commit 3e229811.

add beta2 suffix for dev16 branch

Fix crash when applying code fixes that modify additional files

- Reverted FormatCommandHandler.FormatDocument
- Removed option search configuration for code cleanup

This wasn't entirely broken -- we also call EnsureEditableDocuments
right before we're going to actually modify an additional file. But
that's one-at-a-time which is really chatty if you're using a server-
based source control system. The intent is we do this all up-front,
and so we shall.

This is called when we're trying to check out from source control
the set of files modified. If we don't return the right path, that code
is surprised by the null result and crashes.

some code clean up on new VisualStudioProject and FileChangeWatcher

Inject range indexers

first is clean up on some lock usage that is no longer needed.
second is fixing a bug where it doesn't support same web page to be opened again after closed.

Do not convert mutable value type fields to properties

Fix for perf issues in CompilationWithAnalyzers found from perf traces

Generates fake indexers for arrays that take System.Index and
System.Range.

This produces a new free-threaded, well factored API for adding projects to the
VisualStudioWorkspace. The core type is the VisualStudioProject which is a
free-threaded API that you can use to push information over. CSharpProjectShim,
VisualBasicProject and CPSProject each have an instance of VisualStudioProject
that they push things through.

This also introduces a proper batching API: any consumer of VisualStudioProject
may call CreateBatchScope() which means all future operations are put a single
batch that will be applied at once in a single workspace change. Multiple calls
to CreateBatchScope just stack: it only applies when all scopes are closed. You
could think of the behavior as roughly analogous to an SQL transaction, except
with no rollback capabilities. A batch is only per-project: a batch started on
one project doesn't impact another project. There is no concept of a
cross-project batch, short of just starting two independent batches and
completing them at the same time (which creates two workspace changes.)

The inheritance model here is now smaller. CSharpProjectShim and
VisualBasicProject inherit from AbstractLegacyProject, but that's it. CPSProject
now inherits nothing, and AbstractProject is here purely for TypeScript
back-compat until they're moved onto the new APIs. The expectation is F# and
TypeScript both move to VisualStudioProject, which we make public in some form.
Then AbstractProject will go away.

AbstractLegacyProject (which is used for csproj and vbproj) still is tied to the
UI thread, but the ties should now be more limited and better understood. The
primary tangles right now are having to fetch a few things from IVsHierarchies,
namely some project properties and the folder structure. The plan for now is
AbstractLegacyProject-derived projects will still be called on the UI thread,
and we'll determine a new API to remove those remaining issues for them (or just
move them onto VisualStudioProject.)

The threading guarantee given to all consumers of VisualStudioProject is it can
be called from any thread, and no synchronous calls to the UI thread may be done
at that time. There are a few places where we asynchronously kick off work to
inspect the running document table, but those are async and should never block.

There is a lock hierarchy now instituted: each VisualStudioProject has a lock
which it takes when any method is called on it, this is to ensure
straightforward synchronization of it's data for things like batch
start/stopping, what's in the batch, etc. There is also a lock in
VisualStudioWorkspaceImpl that is acquired when actually modifying the
workspace, which is done through an internal ApplyChangeToWorkspace method so it
can be called from VisualStudioProject more easily. It is permissible for a
VisualStudioProject to call ApplyChangeToWorkspace to acquire the
VisualStudioWorkspaceImpl lock. It is _not_ permissible for a lock holder of
VisualStudioWorkspaceImpl's lock to acquire any project lock. To this end, some
project-to-project tracking information is held in VisualStudioWorkspaceImpl to
avoid mistakes -- although the data is a "per project" concept, putting it in
the project would cause people to take a project lock and risk deadlocks.

This adds an API for the project system to notify us about files that
can generate .cs files in the workspace. The rest of the implementation
is still coming but this unblocks the project system side of things.

This test was broken prior to my change: it never waited for CPS to
have completed design time builds before it asserted that everything
was done. But before, there was no window where the UI thread was idle
and the file wasn't associated with Miscellaneous Files. Now that we're
more async, I think it is the case where it can be, and that trips
things up.

Merge 'features/NullableReferenceTypes' into 'dev16.0.x'

We might disconnect/reconnect on background threads now, so
be ready for that.

Since we're checking the RDT asynchronously, we need a way for
integration tests to confirm that.

1. Check cancellation at multiple places.
2. Run partial tree completion logic sequentially when `AnalysisOptions.ConcurrentAnalysis = false`