Fixes #30271

See #30819

We support dangling project references in the workspace API,
and the ProjectDependencyGraph is only supposed to return references
that exist within the project. Therefore, if we add a project, we have
to check to make sure we didn't have a dangling reference becoming a
real reference, and give inconsistent results.

I expect this to be a rare situation in reality so don't want to spend
a lot of time optimizing for it, but if it happens this will keep
everything in sync.

It's unclear to me why we have another implementation of computing
transitive project references; we'll just call our existing
implementation.

Any time we made a change to the dependency structure of a solution,
we threw away the dependency graph entirely and recomputed it. This
was pretty wasteful, since we'd promptly recompute parts of it as
a part of the workspace solution forking. The allocations were quite
high, often to recompute the (almost) exact same immutable data as
before.

This adds the abilty to take an existing ProjectDependencyGraph and
update it to produce a new graph with project references added, which
reuses whatever data was easily available.

We already have an API for adding multiple project references; let's
just use that at the public entrypoints than trying to maintain
near-duplicate code.

These methods do not return topologically sorted results; not only
is that not something that really makes sense, but they return
IImmutableSets anyways so they have no way to guarantee ordering at all.

Two bugs being fixed here:

1. When we remove a document in a non-batch scenario, we close any
   information related to the open document. If we were in a batch
   scenario, the SetCurrentSolution we do to apply the new Solution
   snapshot didn't go through that. Now we do.
2. UpdateSolutionForBatch wasn't calling the delegates given; this would
   have meant that additional files being added in a batch would have
   been added a regular source files.

The underlying process of removing a document already handled this,
this was an unnecessary block. It was already the case that you could
call OnProjectRemoved to remove the entire project that had open files,
so this didn't really avoid badness in the first place.

in the situation where DebugType is mising and the DebugSymbols property is set to true, the TryGetValue method of the s_debugTypeValues dictionary would throw an exception

In MSBuildWorkspace, there's a fair amount of logic to resolve the metadata references that are passed to the compiler
to project references that are defined on the project. This change adds a fallback in the case that a project reference
can't be matched to one of the metadata references. This is primarily a situation where something is wrong with the project
in it's current configuration. For these cases, MSBuildWorkspace will still attempt to add a project reference but also report
a workspace diagnostic. In addtition, this change removes and reports diagnostics for any unresolved metadata references
passed to the compiler after the reference resolution step occurs. In addition, this change exposed a small bug when
ReferenceOutputAssembly is specified for a project reference, which was caught by an existing test and fixed.

In MSBuildWorkspaceProjectLoader, there is a map of "discovered" projects that stores the results of any project references. If a
project reference can't be loaded (for example, because it is a reference to, say, an F# project), it can end up in the map twice if the
project referencing it is multi-targeted. For example, a multi-targeted C# project that references an F# project will fail when loaded
because the path to the F# project will get added twice with an empty array of ProjectInfos. The reason for this is that the code assumes
that the loaded project will end up in the primary loaded project map, but in this case, the project couldn't be loaded and isn't there. To
avoid this situation, we call TryGetValue on the "discovered" projects map and return the results before trying to load the project again.

Added AddMissingImport CodeRefactoring driven by PasteTrackingService

Added PasteTrackingService that handles the paste command and track
paste information for documents. This paste information can be used
by refactorings to make suggestions based on what was pasted.

Fixes #10272