Improve Project Resource V2 coordinated build performance

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

Exploratory testing of Project Resource V2 in #19678 showed that moving resource builds after AppHost startup achieves the intended earlier dashboard availability, but the coordinated build path can increase time to a fully ready application.

Across six cold-build runs on Windows:

| Application | Dashboard availability | Full application readiness |
|---|---:|---:|
| AspireShop | 18.9% faster | 6.4% slower |
| eShop | 30.7% faster | 35.2% slower |

For eShop, the AppHost build improved from 4.09 s to 1.53 s, but the subsequent generated traversal build took 4.05 s. This suggests there is meaningful opportunity to optimize the coordinated restore/build phase.

The current implementation also writes coordination artifacts under an AppHost-local `.aspire` directory, requiring additional `.gitignore` handling even though these files are intermediate build outputs.

### Describe the solution you'd like

1. **Generate coordination files under the AppHost's configured intermediate output path.**

Resolve `BaseIntermediateOutputPath` for the AppHost and place all generated coordination files under a child such as `$(BaseIntermediateOutputPath)\aspire`. This is the idiomatic location for C# intermediate build outputs, honors projects that customize `obj`, and is generally already ignored by source control. It should remove the need to generate and maintain a separate `.aspire/.gitignore` entry for these files.

2. **Use a solution/project-reference graph for coordinated restore and build.**

The generated `.proj` currently routes discovered projects through `MSBuild` task invocations rather than allowing the normal solution/project-reference restore and build logic to optimize the complete graph.

Consider generating:

- A `.slnx` containing all discovered project resources.
- A generated `.proj` for file-based app resources, with `ProjectReference` items for every `#:project` directive and `PackageReference` items for every `#:package` directive.
- A reference to that generated project from the `.slnx` when file-based apps are present.

Running solution-level restore/build over this graph should allow NuGet and MSBuild to deduplicate and schedule the complete dependency graph up front instead of restoring/building project entries independently.

`.slnx` requires .NET 9 or later. Project Resource V2 is targeting the next major Aspire release, which already requires .NET 10 or later for C# AppHosts/project resources, so Project Resource V2 should simply require .NET 10 or later rather than retaining a fallback for older SDKs.

3. **Enable multi-threaded MSBuild when supported.**

Detect the version of the `dotnet` CLI used for coordinated restore/build. When it is at least `11.0.100-preview.7`, pass `-mt` to both restore and build. Multi-threaded MSBuild has shown significant performance improvements and should be enabled by default for Aspire users with C# resources when the selected SDK supports it. Version detection should correctly compare preview and stable SDK versions and omit the flag for older SDKs.

Suggested acceptance criteria:

- No coordination-generated files are written outside the configured AppHost intermediate output tree.
- Project resources and file-based app `#:project`/`#:package` dependencies participate in one solution-level restore/build graph.
- `-mt` is applied only for supported `dotnet` SDK versions.
- Focused startup benchmarks demonstrate preserved early dashboard availability and improved time to project-resource readiness compared with the implementation in #19678.

### Additional context

Follow-up to #19678 and its exploratory test report: https://github.com/microsoft/aspire/pull/19678#issuecomment-5545217854

Tagging @baronfel for input on the MSBuild and solution-graph approach.