[Epic] Aspire extension: next-generation Aspire support in azd

## Summary

Create a first-party `microsoft.azd.aspire` extension as the next generation of Aspire support in `azd`.

The extension will use the Aspire CLI as the primary compatibility layer so `azd` can support C#, TypeScript/JavaScript, Python, and future Aspire AppHost languages without reproducing Aspire's language-specific runtime protocols.

The existing built-in C# Aspire implementation will enter maintenance mode. It will receive blocking compatibility, security, and reliability fixes, but new Aspire capabilities will be developed in the extension.

## Goals

- Introduce `host: aspire` as the clear public `azure.yaml` contract for Aspire projects.
- Detect and initialize Aspire projects through the extension and Aspire CLI.
- Preserve the `azd` workflows customers rely on: environment management, `up`, provision, deploy, down, pipeline configuration, hooks, output, and no-prompt automation.
- Support App Service, Container Apps, and future deployment environments based on the AppHost model rather than `azure.yaml` host naming.
- Support polyglot Aspire AppHosts according to the support level of the installed Aspire CLI.
- Preserve backwards compatibility for existing `host: containerapp` plus `language: dotnet` projects.
- Retire the built-in implementation only after extension parity and a safe migration path are established.

## Architecture principles

- Invoke the Aspire CLI through its documented machine-readable JSON/NDJSON interfaces.
- Do not depend directly on Aspire's internal JSON-RPC, AppHost server, ATS, DCP, or auxiliary backchannel protocols unless they become supported public contracts.
- Model an Aspire application as one aggregate `aspire` service. The extension does not need to reproduce the built-in importer's synthetic child services.
- Keep generic orchestration, environments, hooks, pipelines, prompts, and telemetry in azd core.
- Keep only the minimum bootstrap detection and legacy compatibility logic in core.
- Align language support and stability claims with the Aspire CLI.

## Proposed configuration

```yaml
services:
app:
host: aspire
project: ./apphost
infra:
provider: aspire
```

`language` is intentionally optional because the Aspire CLI owns AppHost language discovery.

## Workstreams

The linked sub-issues define the implementation phases. Each phase must leave the existing built-in implementation functional until the migration and retirement criteria are met.

## Success criteria

- New Aspire projects initialized by azd use `host: aspire` and the Aspire extension.
- C#, TypeScript/JavaScript, and Python AppHosts can use standard azd workflows where supported by Aspire.
- App Service and Container Apps deployment selection comes from the AppHost.
- Existing Aspire projects continue working without mandatory configuration edits.
- CI/no-prompt, telemetry, documentation, installation, and offline behavior have explicit supported contracts.
- The built-in implementation can be removed without breaking legacy projects.

## Phases

- [ ] #9488 — Phase 0: Freeze and baseline built-in Aspire support
- [ ] #9484 — Phase 1: Validate Aspire CLI integration contracts
- [ ] #9485 — Phase 2: Add extension-driven application detection and initialization
- [ ] #9483 — Phase 3: Implement `microsoft.azd.aspire` providers
- [ ] #9482 — Phase 4: Map complete azd workflows to Aspire
- [ ] #9487 — Phase 5: Add polyglot Aspire support
- [ ] #9486 — Phase 6: Make the extension the default for new Aspire projects
- [ ] #9480 — Phase 7: Migrate legacy built-in Aspire projects
- [ ] #9481 — Phase 8: Retire the built-in Aspire implementation