* Test compositions

* Eliminate TestExportProvider

* Fixes and caching

* Debugger proxies

* Scopes

* Feedback and more fixes

* RemoteHostOptions

* Throw without timeout on invalid thread switches

* EventCollectorTests requires a main thread

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.

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.

The inheritence 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 that type will go away.

Closes #25560

In 2f206670 I changed CodeModel to not open an editor when somebody
called GetStartPoint(), but it turns out that some paths of
GetStartPoint() internally called GetTabSize which assumed the text
was backed by a text buffer. This was the original reason the
EnsureEditor call was added, but I incorrectly determined that the
it was no longer needed. Now we just pass our OptionSet from the
document down and ask that, which will work in all cases.

This brought along some references to Microsoft.VisualStudio.Threading
that we previously didn't have. Nothing was wrong with this, but it
meant I had to fix some namespace qualifications that were assuming the
"Threading" namespace was unambiguous.

Although there are some exceptions this has to catch, we would still
want ContractFailureExceptions and others to flow through. Thus we can
be more precise.

Right now the CleanableWeakComHandleTable is very affinitized, and until
we can change that we're best leaving these as is.

Ensure that an EnvDTE.CodeParameter.Name returns the correct value for parameters defined in metadata

The issue is that the symbol display system will not return a name for a parameter unless
SymbolDisplayParameterOptions.IncludeName is set. This behavior seems like it might ultimately be
a bug in symbol display as that option is intended to control the display the parameters owned
by the targeted symbol, but probably shouldn't affect the display of the targeted symbol. However,
rather than updating symbol display (which would potentially have larger downstream impact), we'll
just include the option in this case.

Ensure that an EnvDTE.CodeParameter.Name returns the correct value for parameters defined in metadata

The issue is that the symbol display system will not return a name for a parameter unless
SymbolDisplayParameterOptions.IncludeName is set. This behavior seems like it might ultimately be
a bug in symbol display as that option is intended to control the display the parameters owned
by the targeted symbol, but probably shouldn't affect the display of the targeted symbol. However,
rather than updating symbol display (which would potentially have larger downstream impact), we'll
just include the option in this case.

* Remove lots of duplicated code
* Add support for testing external code elements

CodeModel.CodeTypeFromFullName should prefer locations within source
files that are not generated (using the same heuristic we use within the
Generate Type dialog to determine whether a source file is "generated").
However, if the locations are *all* within generated sources, just
return the first one.

Scenario: this addresses a scenario where CodeModel.CodeTypeFromFullName
is used to determine the right place to modify user code. In the case of
XAML apps, there are several generated files that shouldn't be modified
(i.e. .g.i.cs .g.cs, etc.). Previously, CodeTypeFromFullName might
return one of these files as a location, breaking whatever feature was
trying to modify the user's code.

Unit tests have been added for this scenario in C# and VB that test a
handful of permutations of generated and non-generated code with partial
classes. Additionally, the Code Model unit testing infrastructure has
been updated to support TestWorkspaces with multiple documents.

Fix #2355 VB Declare Function and Declare Sub should be of kind
vsCMElementDeclareDecl

Now that the comment formatting issue is fixed in the Formatter type, we can run the formatter on the remainder of the VB code base.

closes #1424