Split CI providers out of Fallout.Common into per-provider packages

Sub-issue under #73 (umbrella modularization). Sibling to #72 (tools split).

## Scope

`src/Fallout.Common/CI/` currently bundles all 11 CI provider integrations into a single package. Split each into its own `Fallout.CI.` project + NuGet package.

| Today | New |
|---|---|
| `src/Fallout.Common/CI/AppVeyor/` | `src/Fallout.CI.AppVeyor/` → `Fallout.CI.AppVeyor` package |
| `src/Fallout.Common/CI/AzurePipelines/` | `src/Fallout.CI.AzurePipelines/` → `Fallout.CI.AzurePipelines` package |
| `src/Fallout.Common/CI/Bamboo/` | `src/Fallout.CI.Bamboo/` → `Fallout.CI.Bamboo` package |
| `src/Fallout.Common/CI/Bitbucket/` | `src/Fallout.CI.Bitbucket/` → `Fallout.CI.Bitbucket` package |
| `src/Fallout.Common/CI/Bitrise/` | `src/Fallout.CI.Bitrise/` → `Fallout.CI.Bitrise` package |
| `src/Fallout.Common/CI/GitHubActions/` | `src/Fallout.CI.GitHubActions/` → `Fallout.CI.GitHubActions` package |
| `src/Fallout.Common/CI/GitLab/` | `src/Fallout.CI.GitLab/` → `Fallout.CI.GitLab` package |
| `src/Fallout.Common/CI/Jenkins/` | `src/Fallout.CI.Jenkins/` → `Fallout.CI.Jenkins` package |
| `src/Fallout.Common/CI/SpaceAutomation/` | `src/Fallout.CI.SpaceAutomation/` → `Fallout.CI.SpaceAutomation` package |
| `src/Fallout.Common/CI/TeamCity/` | `src/Fallout.CI.TeamCity/` → `Fallout.CI.TeamCity` package |
| `src/Fallout.Common/CI/TravisCI/` | `src/Fallout.CI.TravisCI/` → `Fallout.CI.TravisCI` package |

Each package contains:

- The `[]` configuration-generator attribute (e.g. `[GitHubActions(...)]`, `[TeamCity(...)]`)
- The YAML/Kotlin/XML configuration model classes
- Any provider-specific environment helpers (e.g. `GitHubActions.Instance` static accessor for `GITHUB_*` env vars during a CI run)
- Per-provider integration helpers (test reporters, artifact uploaders, etc.)

A new `Fallout.CI.Abstractions` package may emerge for the shared base classes (`ConfigurationAttributeBase`, `ConfigurationGenerationGenerator`, etc.) that every provider package depends on. Decision during implementation.

## Mechanical plan

1. **Decide on `Fallout.CI.Abstractions`** — yes / no. If yes, what's in it.
2. Create per-provider projects under `src/Fallout.CI./`. Each references `Fallout.Common` (or `Fallout.CI.Abstractions` if introduced).
3. `git mv` files preserving history; rename namespaces `Fallout.Common.CI.` → `Fallout.CI.`.
4. Update `fallout.slnx` + `Directory.Packages.props`.
5. Update `Build.cs` source for this repo (`[GitHubActions]` attribute usage on `Build`).
6. Update CI generation templates (#39 already touched this — verify).
7. Per-provider tests under `tests/Fallout.CI..Tests/`.
8. Update `fallout-migrate` to rewrite namespaces + add the matching ``.
9. Update `Nuke.Common` shim — either re-export from `Nuke.Common.CI.` (lots of subclassing) or ship matching `Nuke.CI.` shim packages.
10. Migration guide entry (#37).

## Migration impact

- **Breaking for consumers.** New `` + `using Fallout.CI.GitHubActions;` instead of `using Fallout.Common.CI.GitHubActions;`. Both mechanical, `fallout-migrate` should handle.
- **11.0-aligned.** Batch with #72 and the legacy-name removals.

## Done when

- [ ] All 11 CI providers split into their own projects + packages
- [ ] `fallout.slnx` + `Directory.Packages.props` updated
- [ ] This repo's own `Build.cs` consumes the new packages
- [ ] Per-provider tests pass
- [ ] `fallout-migrate` covers the namespace + PackageReference migration
- [ ] `Nuke.Common` shim still works (or per-provider shim packages exist)
- [ ] Release pipeline ships all 11 `Fallout.CI.*` packages
- [ ] Migration guide updated