Split tool wrappers out of Fallout.Common into per-tool projects + NuGet packages

## Problem
`Fallout.Common` is a kitchen sink. It contains:
- Framework basics (`FalloutBuild`, `Target`, parameter injection, etc.).
- ~70 tool wrappers under `src/Fallout.Common/Tools//`: DotNet, MSBuild, Docker, Helm, Kubernetes, AzureKeyVault, Xunit, ReportGenerator, GitVersion, Paket, Boots, Chocolatey, … most of which a typical consumer never touches.

Every consumer pays for every tool — bigger compile times, bigger restore graph, transitive deps for tools they don't use.

## Goal
Make `Fallout.Common` a clean base library:
- Each tool wrapper → its own project + NuGet package.
- Consumers add a `PackageReference` per tool they use.
- Third parties can ship `Foo.Fallout.Tools.` packages on the same architecture without touching this repo.
- We keep maintaining a baseline set of officially supported tools.

## Naming proposal
`Fallout.Tools.` (e.g. `Fallout.Tools.DotNet`, `Fallout.Tools.Docker`, `Fallout.Tools.Helm`). Mirrors the existing `Fallout.Utilities.IO.Compression` / `.Globbing` style.

Layout:
```
src/
Fallout.Common/ # framework basics only
Fallout.Tools.DotNet/
Fallout.Tools.DotNet.csproj
DotNet.json
DotNet.Generated.cs # regenerated
DotNetTasks.cs # hand-written extras
Fallout.Tools.Docker/
...
```

## Mechanical plan
1. New project per tool — references `Fallout.Common` (or a narrower base if we slice further). Targets `net8.0;net9.0;net10.0`.
2. Move `src/Fallout.Common/Tools//` → `src/Fallout.Tools./`, preserving the `.json`/`.Generated.cs` pairing.
3. Update the generator: per-project `namespaceProvider: x => $"Fallout.Tools.{x.Name}"` instead of `Fallout.Common.Tools.{x.Name}`. Namespace flattens — `Fallout.Common.Tools.DotNet.DotNetTasks` → `Fallout.Tools.DotNet.DotNetTasks`.
4. Update `fallout.slnx` + `Directory.Packages.props`.
5. Add per-tool tests under `tests/Fallout.Tools..Tests/`.
6. Roll into the release pipeline so each tool packs separately.

## Migration impact
- **Breaking for consumers.** Add `` and update `using Fallout.Common.Tools.DotNet;` → `using Fallout.Tools.DotNet;`. Both mechanical — fit for `fallout-migrate`.
- **Breaking for shim consumers.** The `Nuke.Common` shim must either re-export the tool surface from `Nuke.Common.Tools.` namespaces (more wrapper code) or split into matching `Nuke.Tools.` shim packages.
- **Belongs in 11.0**, aligned with the existing FALLOUT001/002/003 deprecation sunsets.

## Carve-outs to leave in `Fallout.Common`
Framework-coupled tools probably stay:
- `Tools/Git/` — used by `[GitRepository]` injection.
- `Tools/GitHub/` — used by `ICreateGitHubRelease`.
- `Tools/GitVersion/` — used by `IHazGitVersion`.
- `Tools/MSBuild/` — used by `ProjectModel`.

Borderline:
- `Tools/DotNet/` — used by `IPublish`, `IPack`, `IRestore`, `ITest`. Probably stays.
- `Tools/NuGet/`, `Tools/Paket/` — adjacent to `IPublish`. Maybe stays.

Everything else (Docker, Helm, Kubernetes, Xunit, ReportGenerator, AzureKeyVault, …) splits out.

## Why filed in Backlog
A significant breaking change with no immediate release pressure. Worth doing alongside other 11.0-aligned breaks (legacy `Nuke*` MSBuild prop/env-var removal). Listed here so demand can accumulate; promote to a milestone when planning 11.0.

## Done when
- [ ] Decision recorded on which tools stay (framework-coupled list above) vs split out
- [ ] One tool extracted as proof of concept (`Fallout.Tools.Docker` or similar) — exercises generator, packaging, release pipeline, consumer story
- [ ] Remaining tools migrated (mechanical, after the proof)
- [ ] `fallout-migrate` rewrites the namespace + adds per-tool `` entries
- [ ] Migration guide entry (#37) covers the split
- [ ] `Nuke.Tools.` shim packages, or `Nuke.Common` shim updated to re-export from the new namespaces
- [ ] Release pipeline ships `Fallout.Tools.` packages alongside `Fallout.Common`