This meant some of the StubProjects we create for compatibility shims
(which derive from AbstractProject) will now have this set. Otherwise
we were passing back null, which didn't end well.

We were adding with project unique name, but removing with the
DisplayName, which could change over time. I've renamed the map
to clarify exactly which "name" is being used.

Right now I'm being lazy and just using a foreach across the
ImmutableDictionary rather than converting it to a bidirectional
map. If this ever becomes a perf problem, it's easy to fix.

We stopped populating this, which breaks various things like Live Unit
Testing and some of our persistence stuff.

F# was requesting the ID, which we'd throw on by accident.

There's nothing left but shims at this point, so nothing actually
requires it. Previously something must have been creating it by
accident but we aren't anymore, and F# trying to use it would cause
issues.

The existing shim constructor we had wasn't being used -- I'm not sure
if this is me accidentally refactoring after I had it working, or
they changed their code more recently. In either case, it's easy enough
to add another compat constructor.

We initialize AssemblyName when we create the project with the
project system name (because the workspace requires we have something).
But ocne we get the real path, we need to use the real name.

A confluence of bugs in shell means that using GetServiceAsync to
request the file change service has a chance of deadlocking. For now
we'll just avoid this since this pattern is fine too.

There are some perf issues created by this; they have already been
fixed in later builds of Visual Studio but we can't rely on them
for now.

If the path or output directory is null, you might get nulls in
KeyFileSearchPaths. This is potentially a workaround around
dotnet/roslyn#30349, if that's actually a bug. Or, it's an indication we
shouldn't be using this in the first place.

ASP.NET Web Sites that are opened from the web have a URL as their file
path. We don't want to hand that around to anything else, so skip it.

Our explicit layout was not correct on 64-bit, which we do run these
tests on.

VisualStudioMetadataReferenceManager has implicit UI thread requirements
in it's constructor; for now we'll still trigger an early load of it
when we know we're still on the UI thread.

It's a requirement (eventually) that CreateAndAddToWorkspace be called
free-threaded as well; we'll have to address this at that time.

TypeScript uses the AbstractProject and VisualStudioProjectTracker to
add and remove projects; this adds back a minimal shim for them to use.

We had separate tests for P2P conversion for both legacy shims and
through the CPS APIs. Now tha the code is identical, we'll keep just
the CPS ones.

Right now the underlying FileChangeWatcher still doesn't have support
for requesting that a file watcher *must* be present at a certain point
in time. Fow now, give an explicit "wait on queue" method for tests.

I think this is what the test was intended to do -- otehrwise it's
identical to the test before it.

These were failing due to the shim rewrite, but it seems these are
actualy the correct assertions: the SpecifiedLanguageVersion should
be Default/Latest in the case of those actually being the switch being
passed, and in the case where we do /langversion:14 as a switch,
we should ignore it in favor of the legacy struct.

Using a path the real .NET Framework reference assemblies means that
if you accidentally cause the tests to actually start reading those
files, it'll pass only if you have that version of the framework
installed, which can quickly get confusing.

If creating three projects with three individual asserts, we should
just have three tests.

There are a number of TODOs in this commit that will need to be worked
out.

I almost tried to refactor this and then caught myself.

This stub exists to support F# back compat, which calls this method
to determine if the project has already been added to the solution.

No reason to use it on a background thread just to get MEF services we
could have already gotten.

Noticed that we never did this in Roslyn correctly: the fix is simple.

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.

Workaround for msbuild bug https://github.com/Microsoft/msbuild/issues/3825.

Add a overload to AsynchronousViewTaggerProvider for TypeScript

Fix for InvalidCastException in "Invert If" refactoring

The addition of IThreadingContext to this type's constructor broke
TypeScript, which they already have a build for that deals with the
change. However it requires a simultaneous insertion which is proving
difficult to achieve. Adding this overload (which is admittedly a total
hack) allows TypeScript to continue functioning even with Roslyn's
change.

moved to newer optimization package

Conservatively apply logical not operator to an expression being negated if it is not a binary operation.

Fixes #29434