Bump NuGet.Packaging to 7.9.0 to match the SDK's NuGet version

[ChrisonSimtian]

⚠️ Breaking change — NuGet 7.x does not support netstandard2.0. Taking this bump means Fallout.Tooling and Fallout.Tooling.Generator stop supporting netstandard2.0, and .NET Framework support goes with it. Consumers on those targets must move to net10.0.

Held for the next major. This PR is labelled target/vNext and stays open until we cut that release. See the direction comment on #638.

The .NET 10 SDK loads NuGet.Frameworks 7.9.0.0 into MSBuild, but the pinned NuGet.Packaging 6.14.3 loaded NuGet.Frameworks 6.14.3 into the same build-host process, so every ./build.sh run fails at Compile once CI moved from SDK 10.0.302 to 10.0.400.

What changed

• NuGet.Packaging 6.14.3 → 7.9.0 in Directory.Packages.props. One line, no source changes.

Why

NuGet 7.0 only removed APIs that were already marked obsolete. This repo uses NuspecReader, PackageArchiveReader, PackageFolderReader, VersionRange, NuGetVersion and NuGetFramework. None of them changed.

Nothing in the repository caused the break. global.json pins SDK 10.0.100 with rollForward: latestMinor, so CI takes whatever the runner image ships.

Verification

• ./build.sh Compile fails on main and succeeds on this branch, on SDK 10.0.400.
• Fallout.Migrate.Analyzers.Specs: 14/14 pass.
• Fallout.Build.Specs: 239/242 pass. The 3 GitRepositoryWorktreeSpecs failures are pre-existing and environment-specific — they assert on the git remote identity and fail identically at 6.14.3 in a fork checkout.

Note on the netstandard2.0 targets

Fallout.Tooling (net10.0;netstandard2.0) and Fallout.Tooling.Generator (netstandard2.0) currently still declare those targets. With this bump they restore .NET Framework assets instead and emit NU1701 warnings. Actually removing the targets is separate work for the same major.

Part of #638

[ChrisonSimtian]

Note for whoever cuts the next major and merges this.

#640 pins the SDK to the 10.0.3xx feature band as a temporary measure, because this PR could not be merged. It is labelled bug + target/vCurrent on purpose, so it appears in the release notes if we ship another minor release first.

When this PR lands as part of a major release, two things need doing:

• Add skip-changelog to Pin the SDK to the 10.0.3xx feature band to stop unattended roll-forward #640. In a major release that also carries this fix, the pin is internal housekeeping and should not appear in the notes.
• Revisit the pin itself. Once NuGet.Packaging is on 7.x, the 10.0.3xx restriction is no longer needed, and the roll-forward policy should be chosen deliberately rather than left as the workaround setting.

[IT-VBFK]

Breaking change — NuGet 7.x does not support netstandard2.0. Taking this bump means Fallout.Tooling and Fallout.Tooling.Generator stop supporting netstandard2.0, and .NET Framework support goes with it. Consumers on those targets must move to net10.0.

Does this mean, that building a .NET Framework app stops working or does this only affect the build project?

If former is true: This would then potentially lock out quite a number of users (including me for one project: build project targets .NET10.0 and builds a .NET Framework 4.8 app)
If latter is true: can this then be a "real" (meaning serious) breaking change? Given, that NUKE in its past only worked out, if the build project targeted the .NET (core) version the major part told. Any other constallation has never worked for me, e.g. build project is .NET8.0 and production app was .NET9.0 -> never ran.