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.

Some of these are particularly hard; we have a lazy data structure that
has "I don't know" as something the algorithm needs to deal with.
Unfortunately trying to test through the public Solution APIs often
doesn't work because the Solution code accidentally asks the dependency
graph for things which then invalidates the "I don't know" by causing
it to compute things.

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.