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

[ChrisonSimtian]

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.<Provider> 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 [<Provider>] 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.<Provider>/. Each references Fallout.Common (or Fallout.CI.Abstractions if introduced).
3. git mv files preserving history; rename namespaces Fallout.Common.CI.<Provider> → Fallout.CI.<Provider>.
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 ([P6] Update CI generation templates and tool-wrapper JSON references #39 already touched this — verify).
7. Per-provider tests under tests/Fallout.CI.<Provider>.Tests/.
8. Update fallout-migrate to rewrite namespaces + add the matching <PackageReference>.
9. Update Nuke.Common shim — either re-export from Nuke.Common.CI.<Provider> (lots of subclassing) or ship matching Nuke.CI.<Provider> shim packages.
10. Migration guide entry ([P5] Write NUKE → Fallout migration guide #37).

Migration impact

• Breaking for consumers. New <PackageReference Include="Fallout.CI.GitHubActions" /> + using Fallout.CI.GitHubActions; instead of using Fallout.Common.CI.GitHubActions;. Both mechanical, fallout-migrate should handle.
• 11.0-aligned. Batch with Split tool wrappers out of Fallout.Common into per-tool projects + NuGet packages #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