Adopt TargetFramework aliasing to simplify project infrastructure, especially testing infrastructure

### Motivation

The `src/tests` tree has a recurring pattern where a test that needs to compile for **all** target platforms but with different code paths is split into two sibling `.csproj` files:

- `Foo_TargetWindows.csproj` — sets `` when `$(TargetsWindows) != 'true'`
- `Foo_TargetUnix.csproj` — sets `` when `$(TargetsWindows) == 'true'`

This workaround existed because MSBuild/NuGet had no first-class way to multi-target a project at the **same** effective framework moniker more than once. The two-file split was the only option.

### The new capability: TFM Aliases

[NuGet 7.6 / .NET SDK 10.0.300](https://learn.microsoft.com/en-us/nuget/reference/target-frameworks#multi-targeting-with-duplicate-frameworks) introduced **TFM aliasing**: a `TargetFrameworks` entry can be any arbitrary string ("alias"), and the real framework moniker is supplied by setting `TargetFrameworkIdentifier`, `TargetFrameworkVersion`, and `TargetFrameworkMoniker` in a condition block. Because NuGet uses the resolved moniker for compatibility checks, two aliases can resolve to the same effective framework in the same project — enabling exactly the pattern we need.

https://github.com/dotnet/runtime/pull/128611 has a theoretical example, but there are some gotchas there since there's some globbing infrastructure.

cc @jkoritzinsky @trylek @agocke

This may be of interest for you.