Specify a DistributedApplicationBuilder scoped OpenTelemetry Receiver Resource/Endpoints that can be overridden

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

The Aspire Dashboard provides an excellent out-of-the-box telemetry experience during local development. However, in many deployment scenarios telemetry must be sent to alternative backends (Grafana, Elastic, Jaeger, Azure Monitor, etc.) or routed through an intermediate collector such as OpenTelemetry Collector or Grafana Alloy.

Today, changing the telemetry destination requires manually overriding all telemetry-related environment variables on every affected resource. This is the same approach currently used by hosting integrations such as the OpenTelemetry Collector integration.

Additionally, custom resources often need access to the currently configured telemetry endpoint. Today the only practical solution is to manually retrieve the Aspire Dashboard endpoint from launch settings and recreate the required environment variables. This creates an unnecessary dependency on implementation details and makes custom integrations harder to build.

This leads to duplicated configuration, increased maintenance effort, and inconsistencies between development and deployment environments.

### Describe the solution you'd like

I would like `DistributedApplicationBuilder` to expose a first-class, configurable telemetry endpoint that represents the OTLP receiver used by the application model. This endpoint could then be used as the standard reference for any resource or integration that needs to export telemetry.

For example:

```csharp
public sealed class DistributedApplicationBuilder
{
public EndpointReference TelemetryEndpoint { get; set; }
}
```

or potentially a dedicated telemetry section:

```csharp
builder.Telemetry.Endpoint = collector.GetEndpoint("otlp");
```

This would allow both built-in and custom resources to discover the active telemetry destination without relying on Dashboard-specific implementation details, launch settings, or manually propagated environment variables.

The feature would provide a single source of truth for telemetry routing and make it straightforward to switch between the Aspire Dashboard, OpenTelemetry Collector, Grafana Alloy, or any other OTLP-compatible backend. It would also simplify the development of custom resources and hosting integrations by giving them a standard way to obtain the configured telemetry endpoint.

### Additional context

_No response_

Start by tracing DistributedApplicationBuilder and the existing telemetry endpoint and environment-variable handling described in the issue. Determine how a configurable, overridable OTLP receiver would be exposed to built-in and custom resources; done means resources can discover the selected endpoint without Dashboard-specific settings or manual variable overrides.

Written by the indexing model from the issue text.