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.

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

* Move Index from unary operators to a stand alone node

* Remove indexer hack

* Remove prototype comments

* Testing/fixing IDE services

* Added EE tests

* Rename "Index" nodes to "FromEndIndex"

* More comments

* Some minor fixups and test fixes

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.