Fix VisualStudioWorkspace thread affinity and defer creation

Move to new VS SDK build tools

Add tests to ref return error codes

When we create a ForegroundThreadAffinitizedObject, it captures
what is believed to be the foreground thread at that point. That can be
bad if it hasn't been initialized, as the background thread might be
the assumed initialization. As a terrible, slimy hack, we'll just defer
this until the foreground asserts are happening. The first might slip
through but later requests would then blow up.

The request for the document tracking service could need the UI thread,
which is bad if we're creating the VisualStudioWorkspace on a background
thread. Since there's no reason to do caching until we have something
to cache, we can defer this work.

My earlier refactoring here replaced a call that was doing an 'as' cast
under the covers with a hard cast. It turns out in devenv /build this
service is a different type that doesn't actually implement the
same interfaces, so the distinction was important. This restores the
old behavior.

This causes problems if we're spinning up a workspace on a background
thread. Let's defer until actually having to fetch metadata, which we
don't do in most cases anyways.

Inline Rename: Prevent crash when source control dialogs show

Added tests for VB implicitly defined tuples

added max file limit

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=227513

InlineRenameSession.ApplyReplacementText is called in response to buffer changes. In response to these changes, we want to (1) kick off some background work to calculate the new ConflictResolutionTask, (2) propagate the new replacementText to all buffers on the UI thread, and then (3) apply the results of the ConflictResolutionTask on the UI thread once they're ready.

Prior to this change, steps (1) and (3) were always done together, in sequence, regardless of how (2) was progressing. Since the replacementText propagation started synchronously and stayed on the UI thread, this usually meant that the application of the results of the ConflictResolutionTask would have to wait until the replacementText propagation completed (because it would wait for the UI thread to be available). This worked great, most of the time.

But, if the propagation of the replacementText causes a buffer change in a source controlled document and "Prompt for Checkout" is enabled, then a modal dialog to checkout files appears. Then, the UI thread pumps and allows more work to be scheduled there. Our ConflictResolutionTask could finish calculating conflicts and the application of these conflicts could be scheduled on the UI thread while a dialog is still up (and we are still propagating the replacementText). It would then try to manipulate the undo stack and apply edits to buffers. Since we still have an open undo transaction from the replacementText propagation,
the attempt to manipulate the undo stack would crash.

This change splits the kicking off of the ConflictResolutionTask and the application of the replacements it computes into separately callable methods that aren't automatically chained together. In some cases they can be called in sequence, emulating the old behavior. But when a text buffer edit triggers ApplyReplacementText, we first kick off the ConflictResolutionTask, then propagate the new replacementText, and *then*, once the replacementText is fully propagated (including the handling of any source control modal dialogs), we finally apply the results of the ConflictResolutionTask on the UI thread.

This does not guarantee that *no* reentrancy will ever happen in Inline Rename, but it gets rid of the biggest, obvious culprit. Completely safeguarding would require a larger change, and I think this approach
is the best one given our current RTM escrow timeline, and it will fix the problem for the vast majority of users encountering this problem.

Remove RC3 builds from the README

this is added so that we can reduce chance of OOM when user added massive size text file to solution.

current default max is 100MB. but user can override it through hidden reg key if they want to.

if such file is added, FileTextLoader will throw InvalidDataException and Workspace will raise Workspace Failed event.

in VS host case, we will show the failed event in output windows.

made it to use test option service since option is mutable workspace state which affects all other tests.

It's still obsolete, but adding it breaks people trying to compile
with warn as error enabled.

Fixes #14202

Some more automated tests and test cleanup for the PR#16659

* add end to end stack depth test

* add comment explaining test

* switch to verify diagnostics

* turn parallel build off

* check pointer size in addition to debug/release

removed additional cost I can find from trace compared to code before…

Enable Code Fixes in F# (RC3 regression)

https://github.com/dotnet/roslyn/pull/16659

added tests, made the included tuple2 chunk a CData

Fixes #16352

We're on the UI thread, do the proper step to initialize.

The contract is to return null if the ProjectId didn't come from us.
If we don't have deferred state, then we're not even initialized so
it most definitely didn't come from us.

Fixes Microsoft/visualfsharp#2329

In 44142e5f I removed this code, under the belief that it wasn't
a problem. However, when WpfFact-attributed tests run, we clear the
foreground thread. Some static state (namely the
ForegroundNotificationService) is still trying to operate between test
runs, so it'd see the fallback state and then bad things would happen.
Although there's a number of terrifying things there, for now we'll
just roll it back.