Import existing CI pipelines (GitHub Actions, Azure DevOps) into a Fallout build

## Summary
Fallout can already **generate** CI configuration *from* C# — `[GitHubActions(...)]`,
`[AzurePipelines(...)]`, etc. on the `Build` class emit the workflow files
(`ConfigurationAttributeBase` + `IConfigurationGenerator`). This issue proposes the
**reverse direction**: a best-effort *importer* that reads an existing pipeline
(GitHub Actions `*.yml`, Azure DevOps `azure-pipelines.yml`) and scaffolds the
equivalent Fallout build — the attribute declaration plus stub targets — to lower
the cost of migrating an existing repo onto Fallout.

## Motivation
- The #1 friction for adoption is "I already have a working CI pipeline — porting it
to a C# build is manual busywork." An importer turns that into a one-shot scaffold
the user then refines.
- It pairs naturally with the existing generator: import to bootstrap, then the
generator becomes the source of truth going forward (generate-then-commit, same as
today).

## Proposed shape
A CLI verb, e.g. `dotnet fallout import`:

```
dotnet fallout import --from .github/workflows/ci.yml # autodetect provider
dotnet fallout import --from azure-pipelines.yml --provider azdo
```

Output (best-effort):
1. A `[GitHubActions(...)]` / `[AzurePipelines(...)]` attribute on a generated
`Build.CI.*.cs` partial, with triggers, branch filters, image/matrix, and
concurrency mapped from the source where they have a 1:1 analogue.
2. Stub `Target`s for each distinguishable pipeline step/job, with the original
`run:`/`script:` body dropped into a comment so the author can port it.
3. A migration report listing what mapped cleanly vs. what needs manual attention.

## Scope & honesty about limits
This is **scaffolding, not a transpiler.** CI YAML → typed build targets is lossy:
arbitrary shell, marketplace actions, expression syntax, and matrix fan-out have no
clean 1:1 in a C# build. The deliverable is a *head start* + a clearly-labelled
"TODO: port manually" report — explicitly **not** a guarantee of a runnable build.

## Suggested phasing
- [ ] Provider-agnostic intermediate model (triggers, jobs, steps, matrix, env).
- [ ] GitHub Actions YAML → intermediate model parser.
- [ ] Intermediate model → Fallout `Build.CI.*.cs` emitter (reuse the existing
`Configuration/` object graph where possible).
- [ ] Azure DevOps YAML → intermediate model parser.
- [ ] `import` CLI verb + migration report.

## Open questions
- Reuse the existing `Configuration/` object model (currently generation-only) as the
shared intermediate representation, or a separate import model?
- How far to map marketplace actions (`actions/checkout`, `setup-dotnet`) — recognise
a known-set and map to Fallout equivalents, or always emit a TODO?
- GitLab CI / other providers in scope later, or GitHub + AzDO only?