Custom Service Discoverability

## Description

Enable extension developers to provide service discovery capabilities that leverage framework-specific configuration and manifests (e.g., Aspire AppHost, Spring Boot configuration), allowing automatic detection of application components without requiring explicit entries in `azure.yaml`.

## Current Limitations

- Developers using frameworks like .NET Aspire or Spring Framework already have rich ecosystem manifests defining application components
- These components must be duplicated/redeclared in `azure.yaml` for `azd` to recognize them
- Manual synchronization between framework manifests and `azure.yaml` creates:
- Duplication of configuration
- Potential for drift and inconsistencies
- Additional maintenance burden
- Barrier to adoption for framework users

## Use Cases

### 1. Aspire Extension
- Dynamically detect application components from AppHost model
- Discover services, databases, caches, message brokers defined in Aspire
- Map Aspire resources to Azure infrastructure automatically
- No need to duplicate service definitions in `azure.yaml`

### 2. Spring Framework Extension
- Parse Spring Boot configuration files (`application.yml`, `application.properties`)
- Detect Spring Cloud services, data sources, messaging components
- Discover microservices from Spring Cloud Config
- Auto-detect service dependencies and relationships

### 3. Other Framework Examples
- Docker Compose: Discover services from `docker-compose.yml`
- Kubernetes: Detect services from Helm charts or K8s manifests
- Terraform: Parse module definitions for service discovery

## Acceptance Criteria

- Extension API for registering custom service discovery providers
- Service discovery hooks integrate with `azd` service model
- Discovered services available to all `azd` commands (`provision`, `deploy`, `monitor`, etc.)
- Backward compatibility with `azure.yaml`-defined services
- Merge/conflict resolution when services defined in both framework manifest and `azure.yaml`
- Service metadata schema supporting:
- Service name and type
- Dependencies and relationships
- Framework-specific configuration
- Azure resource mappings

## Proposed Implementation

### 1. Service Discovery Provider Interface
```go
type ServiceDiscoveryProvider interface {
DiscoverServices(ctx context.Context, projectPath string) ([]Service, error)
SupportsFramework(projectPath string) bool
}
```

### 2. Discovery Registration
- Extensions register discovery providers via manifest or API
- `azd` invokes discovery providers for installed extensions
- Merge discovered services with `azure.yaml` services

### 3. Priority and Conflict Resolution
- Define precedence rules (e.g., `azure.yaml` overrides discovered services)
- Allow extensions to specify merge strategies
- Validation to detect conflicts and warn users

## Related Issues

- #5767 (Extension Enhancements Epic) - Core framework capability
- #4989 (Extension Developer Documentation) - Would document service discovery patterns

## Benefits

- Eliminates configuration duplication for framework users
- Reduces barrier to adoption for developers already using frameworks
- Automatic synchronization between framework and Azure configuration
- Improved developer experience and productivity
- Enables framework-specific optimizations and best practices
- Foundation for intelligent infrastructure generation

## Additional Considerations

- Performance implications of service discovery (caching, lazy loading)
- Error handling when framework manifests are invalid or incomplete
- Support for multi-framework projects
- Integration with `azd init` workflow for automatic framework detection
- Telemetry on discovered vs. explicit services
- Documentation for extension authors on implementing discovery providers