fix(testing): restore .NET Framework targets for the testing packages

[glennawatson]

What kind of change does this PR introduce?

Fix.

What is the new behavior?

ReactiveUI.Testing and ReactiveUI.Testing.Reactive ship net462, net472 and net481 again, alongside the modern net8.0 - net11.0 targets. Verified by packing both projects and listing the package contents:

ReactiveUI.Testing.nupkg           ReactiveUI.Testing.Reactive.nupkg
  lib/net462                         lib/net462
  lib/net472                         lib/net472
  lib/net481                         lib/net481
  lib/net8.0 net9.0 net10.0 net11.0  lib/net8.0 net9.0 net10.0 net11.0

The .NET Framework public surface is byte-identical to the net8.0 baseline, so nothing is reduced on the older frameworks.

What is the current behavior?

Closes #4420

Since v23 both packages set <TargetFrameworks>$(ReactiveUIModernTargets)</TargetFrameworks>, which is net8.0;net9.0;net10.0;net11.0. The ReactiveUI package they exist to test targets $(ReactiveUIFinalTargetFrameworks), which does include $(ReactiveUIFrameworkTargets) (net462;net472;net481). So a project on .NET Framework could reference ReactiveUI but not its testing helpers.

Note for anyone reading the issue: it points at ReactiveUITestingTargets in Directory.Build.props. That property is a red herring here - it is consumed only by test projects under src/tests, never by the shipped packages. The actual driver was ReactiveUIModernTargets in the two csproj files.

What might this PR break?

• No source changed, and no public API changed on any existing target framework. The four modern TFM baselines regenerate byte-identically.
• The two packages now build three additional target frameworks each, so pack and CI time grow slightly.
• ReactiveUI.Testing.Reactive pulls Microsoft.Reactive.Testing on the new frameworks; it resolves and compiles clean on all three.

Checklist

• I have read the Contribute guide
• Tests have been added or updated (for bug fixes / features)
• Docs have been added or updated (for bug fixes / features)
• Changes target the main branch
• PR title follows Conventional Commits

Additional information

The PublicAPI baselines for the six new (project, TFM) pairs were produced with the repo's own tools/generate-publicapi.sh, which the tooling README already names as the step for "after adding a new target framework to a tracked library". Running it over both projects regenerated all 14 pairs; the eight pre-existing ones came back unchanged, which is the check that the generator is deterministic here and that no existing surface moved.

Verified on Linux:

• dotnet build reactiveui.slnx -c Release -t:Rebuild - 0 warnings, 0 errors.
• Both testing projects rebuild clean across all seven target frameworks.
• 4216 tests pass across ReactiveUI.Tests, ReactiveUI.Tests.Reactive, ReactiveUI.Testing.Tests and ReactiveUI.Builder.Tests.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.35%. Comparing base (07989b5) to head (0c75fc7).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4427   +/-   ##
=======================================
  Coverage   93.35%   93.35%           
=======================================
  Files         347      347           
  Lines       14921    14921           
  Branches     1553     1553           
=======================================
  Hits        13929    13929           
  Misses        731      731           
  Partials      261      261           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.