[Aspire extension] Phase 2: Add extension-driven application detection and initialization

Parent epic: #9479

## Objective

Enable an extension to authoritatively detect and initialize applications before an `azure.yaml` exists.

## Problem

Host, framework, and provisioning providers are resolved from project configuration. `azd init` needs to discover the Aspire extension before that configuration exists, creating a bootstrap gap.

## Scope

- Design a reusable extension capability such as `application-detector-provider` or `project-initializer-provider`.
- Allow providers to return:
- Candidate project/AppHost paths.
- Project kind and language.
- Detection evidence and confidence.
- Required tools and minimum versions.
- A proposed service/project configuration.
- Confirmation data needed by the standard init UX.
- Add provider metadata and registry discovery support.
- Define interactive, no-prompt, offline, missing-extension, and conflicting-detector behavior.
- Keep only lightweight Aspire candidate recognition in core so azd can discover or install the extension.
- Have the Aspire provider use Aspire CLI discovery rather than duplicating language detection.

## Deliverables

- Extension protocol and SDK support.
- Core provider discovery and lifecycle integration.
- A demonstration provider and tests.
- Aspire extension integration producing `host: aspire` configuration.

## Exit criteria

- `azd init` can delegate Aspire detection and configuration generation to an installed extension.
- The capability is generic and usable by future ecosystems.