Modularize Fallout.Common — break the framework into focused packages

Umbrella issue: **`Fallout.Common` becomes a clean base library; other concerns ship as focused, optional packages.** Mirrors the pattern already set by `Fallout.Utilities.IO.Compression` / `.Globbing` / `Fallout.Utilities.Net` / `Fallout.Utilities.Text.{Json,Yaml}`.

## Goal
Consumers add a `` per concern they use, instead of the whole kitchen sink. Third parties ship matching `Foo.Fallout..` packages without forking. Core stays slim and fast to compile.

## Current state — `src/Fallout.Common/`
```
Attributes/ — framework-level: [Parameter], [Secret], [Solution], [GitRepository]. Stays.
CI/ — 11 CI providers in one bag (AppVeyor, AzurePipelines, Bamboo, Bitbucket, Bitrise,
GitHubActions, GitLab, Jenkins, SpaceAutomation, TeamCity, TravisCI). Split.
ChangeLog/ — Markdown changelog parsing. Maybe split.
Gitter/ — Gitter chat integration. Almost certainly split (niche).
IO/ — Path/file helpers coupled to framework runtime. Stays (standalone bits are already
"Utilities.IO.*" packages).
Tools/ — ~70 tool wrappers in one bag. Split — tracked in #72.
Utilities/ — General helpers (collections, reflection, encryption, etc.). Stays.
```

## Proposed split

| Today | New | Rationale |
|---|---|---|
| `Fallout.Common.CI.AppVeyor` | `Fallout.CI.AppVeyor` | One package per provider; consumer picks |
| `Fallout.Common.CI.GitHubActions` | `Fallout.CI.GitHubActions` | ditto |
| `Fallout.Common.CI.TeamCity` | `Fallout.CI.TeamCity` | ditto |
| `Fallout.Common.CI.AzurePipelines` | `Fallout.CI.AzurePipelines` | ditto |
| `Fallout.Common.CI.*` (remaining 7) | `Fallout.CI.*` | ditto |
| `Fallout.Common.Tools.` (×70) | `Fallout.Tools.` | Tracked in #72 |
| `Fallout.Common.ChangeLog` | `Fallout.ChangeLog` | Decide: core or optional? |
| `Fallout.Common.Gitter` | `Fallout.Gitter` | Niche — should be optional |

Staying in `Fallout.Common`: `Attributes/`, `IO/`, `Utilities/`, plus any tool tightly coupled to a framework component (Git, GitHub, MSBuild for ProjectModel, likely DotNet for IPack/IPublish/ITest — see #72 carve-outs).

## Phases

| Phase | Issue | Status |
|---|---|---|
| Pattern established | (done) | ✅ `Fallout.Utilities.*` sub-packages exist as a working model |
| Tool wrappers | #72 | 🟡 Filed |
| CI providers | (sub-issue) | ⬜ TBD |
| ChangeLog, Gitter, other helpers | (file individually) | ⬜ TBD |
| Update `fallout-migrate` | folds into the per-area split PRs | ⬜ |
| Update `Nuke.Common` shim or split into per-area shims | ditto | ⬜ |
| Migration guide update | #37 | ⬜ Open |

## Why one umbrella issue
- Captures the architectural decision in one place.
- Sub-issues track each split as concrete, independently shippable work.
- Done-state per sub-issue rolls up here.
- 11.0-aligned: breaking, batches with the other 11.0 removals (legacy `Nuke*` MSBuild props, env vars, credential store, telemetry property).

## Done when
- [ ] Decision recorded: which areas split, which stay
- [ ] `Fallout.CI.*` split out (sub-issue)
- [ ] `Fallout.Tools.*` split out (#72)
- [ ] `Fallout.ChangeLog`, `Fallout.Gitter` decision + split (sub-issues)
- [ ] `fallout-migrate` rewrites namespace + PackageReference for moved areas
- [ ] `Nuke.Common` shim (or per-area shims) keep working
- [ ] Migration guide (#37) covers the split
- [ ] Release pipeline ships the new packages alongside `Fallout.Common`