Fluent API for Client-Side Load Balancing (bypass DCP proxy when needed

## Feature Request: Fluent API for Client-Side Load Balancing (bypass DCP proxy when needed)

### Problem
- **DCP Proxy opacity**: In local Aspire/DCP, every HttpClient points at a single proxy endpoint (`localhost:xyz`). Even if `.WithReplicas(3)` is configured, the client never sees multiple targets, so client-side load balancing (CSLB) or health filtering can’t be exercised.
- **Kubernetes parity gap**: When we move to K8s, we often want headless services or direct Pod resolution (especially for gRPC). `Microsoft.Extensions.ServiceDiscovery` doesn’t expose a fluent, code-first API to express “use Aspire discovery + RoundRobin” or “bypass proxy in dev to test CSLB logic before deploying.”
- **gRPC mismatch**: gRPC in .NET already supports client load balancing via `ServiceConfig`. Having only server-side proxying breaks the native gRPC design (single subchannel).

### Desired API
```csharp
builder.Services
.AddHttpClient("orders", client =>
{
client.BaseAddress = new Uri("http://orders-service/");
})
.AddServiceDiscovery() // logical name → multiple endpoints
.AddRoundRobinLoadBalancer(); // explicit strategy in code
```

### Key Requirements
1. Simple fluent API (`AddRoundRobinLoadBalancer`, `AddRandomLoadBalancer`, etc.).
2. Works with `AddServiceDiscovery()` (Aspire discovery or Kubernetes discovery, including headless services).
3. Routes only to healthy endpoints (respect readiness/health checks).
4. Ability to **bypass the DCP proxy locally** so teams can test CSLB before shipping to Kubernetes.
5. Parity with tooling like Steeltoe or Project Tye, which already exposed these capabilities.

### Additional Context
- Many teams coming from **Steeltoe.Discovery.Consul** or Tye expect code-first control over client load balancing.
- Config-only approaches (appsettings) aren’t ideal for library authors or ServiceDefaults packages that need to enforce policies.
- gRPC & high-throughput scenarios benefit from direct Pod routing; DCP proxying hides the underlying architecture and prevents realistic perf testing.
- Once deployed to Kubernetes, we’d like Aspire + Service Discovery to behave more like gRPC’s `ServiceConfig`, with strategies selectable in code.