Provisioning Provider Extensibility

## Description

Enable extension developers to implement custom provisioning providers, extending beyond the built-in Bicep and Terraform support. This allows developers to use their preferred Infrastructure-as-Code (IaC) tools and scripting approaches to provision Azure resources through `azd`.

## Current Limitations

- `azd` currently supports only Bicep and Terraform as provisioning providers
- Developers using other IaC tools must work outside of `azd` workflow or convert to Bicep/Terraform
- Limited flexibility for organizations with established IaC tooling and patterns
- No extensibility for custom provisioning approaches (e.g., imperative scripts, custom orchestration)

## Acceptance Criteria

- Extension API for registering custom provisioning providers
- Provisioning provider interface supporting standard `azd` lifecycle:
- `provision` - Create/update infrastructure
- `destroy` / `down` - Delete infrastructure
- Plan/preview operations
- State management and outputs
- Provider selection mechanism (automatic detection or explicit configuration)
- Integration with `azd provision`, `azd down`, and `azd up` commands
- Support for provider-specific configuration and parameters
- Output handling to expose connection strings, endpoints, and resource IDs to services
- Error handling and rollback capabilities

## Candidate Provisioning Providers

### 1. Pulumi
- Support for multiple programming languages (TypeScript, Python, Go, C#)
- Rich ecosystem of providers and components
- State management via Pulumi service or self-managed backends

### 2. Terraform (Enhanced)
- Fully-featured Terraform provider (migrate/enhance existing core support)
- Support for Terraform Cloud/Enterprise
- Module registry integration
- Advanced state management

### 3. Azure CLI Scripts
- Custom scripts leveraging `az` CLI commands
- Imperative provisioning approach
- Flexibility for complex or custom scenarios
- Useful for organizations with existing CLI-based automation

### 4. ARM Templates
- Standard raw ARM (Azure Resource Manager) JSON templates
- Support for ARM template specs
- Linked templates and nested deployments
- Integration with Azure deployment history

### 5. Azure CDK (Cloud Development Kit)
- Define infrastructure using familiar programming languages
- Higher-level abstractions over ARM/Bicep
- Type-safe infrastructure definitions
- Integration with existing codebases

## Proposed Implementation

### 1. Provisioning Provider Interface
```go
type ProvisioningProvider interface {
Name() string
Initialize(ctx context.Context, config ProviderConfig) error

// Core operations
Provision(ctx context.Context, options ProvisionOptions) (*ProvisionResult, error)
Destroy(ctx context.Context, options DestroyOptions) error
Preview(ctx context.Context, options PreviewOptions) (*PreviewResult, error)

// State and outputs
GetOutputs(ctx context.Context) (map[string]interface{}, error)
GetState(ctx context.Context) (*ProviderState, error)
}
```

### 2. Provider Registration
- Extensions register provisioning providers via manifest or API
- Provider discovery during `azd init` or explicit configuration
- Provider selection in `azure.yaml`: `infra.provider: pulumi` or auto-detection

### 3. Configuration Schema
```yaml
infra:
provider: pulumi # or terraform, azurecli, arm, azurecdk
path: ./infra
providerConfig:
# Provider-specific configuration
stackName: dev
backend: azureblob
```

### 4. Integration Points
- Outputs from provisioning flow to environment variables
- Service configuration injection from infrastructure outputs
- Consistent error handling and logging across providers
- Telemetry on provider usage

## Use Cases

### 1. Pulumi-First Organizations
- Development team already uses Pulumi across projects
- Leverage existing Pulumi modules and patterns
- Use `azd` for deployment orchestration while keeping Pulumi for IaC

### 2. Azure CLI Script Migration
- Existing provisioning scripts using `az` CLI
- Gradual migration path to declarative IaC
- Custom provisioning logic not easily expressed in templates

### 3. ARM Template Users
- Organizations with ARM template investments
- Compliance requirements to use ARM templates
- Integration with Azure Policy and Blueprints

### 4. Azure CDK Adoption
- Developers preferring code-first infrastructure
- Type-safe infrastructure definitions
- Seamless integration with application code

## Related Issues

- #5767 (Extension Enhancements Epic) - Core extensibility feature

## Benefits

- Developer choice and flexibility in IaC tooling
- Lower barrier to adoption for teams with existing IaC investments
- Enables migration scenarios (gradual transition between tools)
- Community can contribute provider implementations
- Organizations can implement custom provisioning orchestration
- Consistent `azd` workflow regardless of underlying IaC tool

## Additional Considerations

- Provider versioning and compatibility
- State management strategies (local vs. remote)
- Provider-specific error handling and diagnostics
- Performance implications of provider abstraction
- Security considerations (credential handling, state encryption)
- Documentation and examples for each provider
- Testing and validation framework for providers
- Provider capability matrix (what features each provider supports)
- Fallback behavior when provider unavailable
- Migration tools between providers (e.g., Bicep to Pulumi)