Update .NET target from net8.0 to net10.0

.NET 8 reaches end of support on 2026-11-10. .NET 10 is the current LTS (supported through
November 2028). We need net10.0/net10.0-windows coverage for our modern target frameworks.

This assumes #161 has landed, so the .NET Framework targets are already net462;net48 and
System.Resources.Extensions / SIL.ReleaseTasks / System.ServiceModel.* are already on
current versions. The .NET Framework and netstandard2.0 targets are unaffected by this issue.

Decision needed first

Do we replace net8.0 or add net10.0 alongside it? Both are on the table; see the consumer
survey in the comments for what each costs downstream.

• Replace: simplest, but it is a breaking change —
  L10NSharp.Windows.Forms, L10NSharp.CheckOrFixXliff and L10NSharp.ExtractXliff would no
  longer have assets that apply to a net8.0/net9.0 consumer. Requires +semver:major
  (see the Semantic Versioning section of the README).
• Add alongside (net8.0;net10.0): non-breaking (+semver:minor), at the cost of a longer
  build matrix, until .NET 8 goes out of support in November 2026.

Note that the L10NSharp core package itself targets netstandard2.0 (not net8.0), so it is
unaffected either way; only the three packages listed above and the test/sample projects carry a
net8.0* TFM.

Changes required

The sites are the same either way — the decision above only settles whether each net8.0* TFM is
replaced by its net10.0* counterpart or joined by it.

Target frameworks:

• src/CheckOrFixXliff/CheckOrFixXliff.csproj:5 — $(TargetFrameworks);net8.0 → net10.0
• src/ExtractXliff/ExtractXliff.csproj:5 — $(TargetFrameworks);net8.0 → net10.0
• src/L10NSharp.Tests/L10NSharp.Tests.csproj:3 — $(TargetFrameworks);net8.0 → net10.0
• src/L10NSharp.Windows.Forms/L10NSharp.Windows.Forms.csproj:4 — net8.0-windows → net10.0-windows
• src/L10NSharp.Windows.Forms/L10NSharp.Windows.Forms.csproj:15 — the
  '$(TargetFramework)' == 'net8.0-windows' condition guarding the System.ServiceModel.*
  package references
• src/L10NSharp.Windows.Forms.Tests/L10NSharp.Windows.Forms.Tests.csproj:3 — net8.0-windows → net10.0-windows
• src/SampleApp/SampleApp.csproj:3 — net8.0-windows → net10.0-windows

CI:

• .github/workflows/CI-CD.yml:37 — dotnet-version: 8.0.x → 10.0.x
• .github/workflows/CI-CD.yml:51 — the Linux test step's --framework net8.0 → net10.0.
  This is the only step that runs on Ubuntu, so it is our sole cross-platform coverage; it must
  keep working.
• Confirm the windows-latest and ubuntu-latest runner images ship (or setup-dotnet
  installs) a .NET 10 SDK, and that Autobuild in .github/workflows/codeql.yml still resolves
  an SDK that can build the new TFMs.

Docs:

• CHANGELOG.md entry under [Unreleased] (### Changed, marked BREAKING CHANGE if we drop
  net8.0), and the +semver:major (or :minor) marker on the commit.

Likely follow-on work / risks

These are the parts most likely to turn a one-line TFM bump into real work:

• GitVersion.MsBuild 5.11.1 (all packable projects) predates the .NET 10 SDK and may not load
  under it. Moving to GitVersion 6.x means migrating GitVersion.yml, which still uses the v5
  schema (mode: ContinuousDeployment, tag: on each branch — renamed to label: in v6, with
  changed ContinuousDeployment semantics). Getting version numbers wrong here affects what gets
  published to nuget.org, so this deserves care.
• Test tooling is from 2022: Microsoft.NET.Test.Sdk 17.4.0, NUnit 3.13.3,
  NUnit3TestAdapter 4.3.2. These are likely to need bumping to run on a .NET 10 SDK / VSTest.
  Note that .github/workflows/CI-CD.yml invokes dotnet test against pre-built DLLs
  (--no-build output\Release\net462\*Tests.dll), so adapter/runner changes can break CI in ways
  a local dotnet test will not show.
• System.ServiceModel.Http / System.ServiceModel.Primitives 8.1.2 — check for a version
  aligned with .NET 10 and re-verify the BingTranslator / generated WCF proxy code, which #161
  already had to adjust for API removals. (Related: #163 — the Bing API itself is retired, so this
  code may be on its way out regardless.)
• Microsoft.SourceLink.GitHub 1.1.1 is redundant on .NET 8+ SDKs (SourceLink is built in).
  Harmless, but a good opportunity to drop it if it causes friction.
• LangVersion is pinned to 8.0 in Directory.Build.props for all TFMs. Not required to
  change, but if we want newer C# on the modern target only, this is where it would happen.
  Out of scope unless something forces it.

Verification

• dotnet build L10NSharp.sln clean across net462, net48, netstandard2.0, net10.0,
  net10.0-windows (plus net8.0* if retained)
• dotnet test passes on Windows (all TFMs) and on Linux (--framework net10.0)
• SampleApp.exe launches for net462, net48, and net10.0-windows
• Generated .nupkgs contain the expected lib/ folders and the version number is what
  GitVersion produced before the change (i.e. no accidental version regression)

Drafted by Claude Opus 5 (1M context) (claude-opus-5[1m]) via Claude Code.

First resolve whether to replace net8.0 or add net10.0 alongside it, using the consumer survey in the comments. Then update the listed project files and .github/workflows/CI-CD.yml, and inspect .github/workflows/codeql.yml, GitVersion.yml, and Directory.Build.props for compatibility concerns. Run the solution build and Windows/Linux test commands, then verify the SampleApp and generated package contents and version.