Stop using ProjectGraph for static graph restore

[zivkan]

Bug

Fixes: NuGet/Home#11680

Description

When a project has a ProjectReference with SetTargetFramework, MSBuild's ProjectGraph API will only give us the one inner build, no outer build or any of the other inner builds. So, to get around it, we take "static graph"'s philosophy of building a bunch of immutable ProjectInstance evaluations, but we walk the graph ourselves, where we can control ignoring SetTargetFramework and therefore ensuring we always get the correct outer build and all inner builds.

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc. N/A

[zivkan]

Performance Testing

Tested static graph restore performance on OrchardCore using scripts/perftests/RunPerformanceTests.ps1 with -staticGraphRestore. A .NET SDK 10.0.202 installation was patched using the
SDKPatchTool from the Entropy repo.

Three variants were tested:

• change0: This branch's first commit (single-threaded manual graph walk)
• change1: Parallel project evaluation using BlockingCollection + Environment.ProcessorCount workers
• change2: Same as change1, but also parallelizing inner builds (per-TFM evaluations)

Scenario	dev (ProjectGraph)	change0 (single-thread)	change1 (parallel projects)	change2 (parallel projects+TFMs)
arctic (clean)	25.1s	26.7s	20.6s	22.3s
cold	11.1s	15.9s	11.1s	11.3s
offline	4.2s	7.1s	4.5s	4.4s
force	3.3s	6.1s	3.5s	3.4s
noop	2.7s	5.6s	2.9s	2.8s

Copilot says that OrchardCore is mostly or entirely single targeting projects, so it's probably not a good repo to test the "change2" build. The noop and force scenarios shows it's not easy to match MSBuild's perf, but it's around 100ms different, which is insignificant from a human perspective, but just under 4% in percentage terms. I'm not sure how it plays out in a huge repo with 1000+ projects, or when projects have a lot of multi-targeting.