test(benchmarks): add BenchmarkDotNet baseline for the .slnx parser

[ChrisonSimtian]

First benchmark project in the repo — establishes a baseline for the `.slnx` parser inlined in #248. Once landed, optimisation experiments (e.g. "replace the inlined parser with a proper XmlSerializer impl") can compare against concrete numbers instead of guessing.

Summary

New project at `tests/Benchmarks/Fallout.Persistence.Solution.Benchmarks/`:

Aspect	Choice
Framework	BenchmarkDotNet 0.14.0 (added to `Directory.Packages.props`)
Scenarios	`[Params(1, 10, 100, 1000)]` project counts × `[Params(false, true)]` folder layout = 8 measurements
Fixtures	Generated programmatically in `[GlobalSetup]` — deterministic, no committed binary blobs
Allocations	`[MemoryDiagnoser]` reports allocs + Gen0/1/2 counts alongside wall-time
What's measured	`SolutionSerializers.GetSerializerByMoniker(path).OpenAsync(...)` end-to-end — the parser path; facade wrapping excluded
CI behaviour	Build-only (the benchmark project compiles via `dotnet build fallout.slnx`); execution is local-only via `dotnet run -c Release`

Why this shape

• Programmatic fixtures: deterministic across machines + future-proof if the .slnx format gets more attributes; no `tests/Benchmarks/.../fixtures/*.slnx` to maintain.
• Skip CI execution: GitHub Actions shared runners are noisy. Numbers from CI would shift run-to-run for reasons unrelated to code. If we ever want continuous benchmark tracking, a dedicated machine + results-database is the right shape — explicit non-goal here.
• `tests/Benchmarks/` precedent: matches the `tests/Consumers/` shape from test(consumers): add NUKE + Fallout consumer compatibility sentinels #256 — a sibling "this is a non-test test" directory.

How to run locally

```sh

all scenarios:

dotnet run --project tests/Benchmarks/Fallout.Persistence.Solution.Benchmarks/ -c Release --filter '*'

one method, full sweep:

dotnet run --project tests/Benchmarks/Fallout.Persistence.Solution.Benchmarks/ -c Release --filter 'SlnxParseBenchmarks'
```

`Release` is required — BenchmarkDotNet refuses Debug builds anyway. Full sweep takes ~3-5 minutes.

What this is NOT

• Not an optimisation PR. Baseline only. Decision on whether to rewrite the parser is downstream of seeing real numbers.
• Not a broader-coverage push. `tests/Benchmarks/` should grow over time — tracked in Expand BenchmarkDotNet coverage to other performance-critical paths #258 (tool wrappers, source generators, globbing, etc.).

Test plan

• `dotnet build fallout.slnx` — green
• BenchmarkDotNet enumerates all 8 scenarios on local quick-run
• CI green on PR
• (after merge) maintainer runs the full sweep locally + captures baseline numbers somewhere — the README on the benchmark project, a follow-up issue, or a wiki page.