HttpLoggingInterceptor is not complete enough to use as a true telemetry extension point

## Summary

The current incarnation of HttpLoggingInterceptor allows limited extensibility of Log lines, but is insufficient to also be used for other forms of telemetry needed for operational services. Most importantly it is called prior to the response being completely sent - this means that the latency of the call is not known (and cannot be used for manipulating metrics counters) and that there is a risk of an exception being thown after the OnResponseAsync callback occurs leading to erroneous measurements of success.

## Motivation and goals

Any services operating at scale will require both logging and metrics as part of their operational telemetry. For HTTP services this means a reliable means of measuring and recording each incoming HTTP request in terms of:
* success (did it complete successfully with an appropriate status code)
* latency (end to end)
* any error details (in the failure case)

Currently the HttpLogging middleware does a reasonable job of allowing a logging solution for incoming HTTP requests, although ideally it would allow the developer some control over the LogLevel (so that failing requests could be promoted to Warning or Error), LogCategory (allowing easy rerouting of just the request completion logs), and potentially ID (to help prevent id clashes).
The current system can be used to log a single combined log line if the CombineLogs option is set in the HttpLoggingOptions, and Duration can be added there to help measure latencies.

However, the callback for OnResponseAsync is fired before the response complete. This can lead to multiple issues:
* The callback can record a log line detailing success for a call which later fails during the response write
* The duration is not available at this point, so the extension point can not be used to update metrics associated with latency (and given the previous point it cannot be used to reliably update metrics around success counts either).

## In scope

Ideally the HttpLogging middleware could be expanded to provide a more complete set of extension points for people implementing operational telemetry. Ideally it would guarantee a single callback firing among the following set:
* OnResponseCompletedAsync (after a response is successfully transmitted, with latency data provided)
* OnErrorAsync (after an unhandled exception is thrown, with details of the exception)

This starts to look a lot like the current HostingDiagnostics features, which are also currently problematic due to the risk of double counting in error cases, and many of the event payloads being internal/private and requiring reflection to be used. Currently there is no clear path for a developer wishing to add custom telemetry to the system aside from adding a custom middleware layer. When being called at scale this risks accidentally adding large numbers of allocations/GC strain leading to system performance degradation over time.

## Out of scope

Scenarios you explicitly want to exclude.

## Risks / unknowns

There is some risk here that if the callbacks are inline that they will still potentially impact performance. Ideally there would be some decoupling here to minimize risk.

## Examples

```
public class MyHttpTelemetryInterceptor : IHttpLoggingInterceptor
{
public ValueTask OnResponseCompleteAsync(HttpLoggingInterceptorContext logContext)
{
// Enrich log line based on context values
EnrichLog(logContext.HttpContext);

// Update status based counters
UpdateSuccessCounters(logContext.HttpContext, logContext.GetDuration());
}

public ValueTask OnErrorAsync(HttpLoggingInterceptorContext logContext)
{
// Enrich log line based on exception details
EnrichLog(logContext.HttpContext, logContext.Exception);

// Update failure counters
UpdateFailureCounters(logContext.HttpContext, logContext.GetDuration(), logContext.Exception);
}
}

```

Start by reviewing HttpLoggingInterceptor, IHttpLoggingInterceptor, HttpLoggingOptions, and the HostingDiagnostics features to understand the current callback lifecycle and response-completion behavior. Compare the existing interceptor callbacks with the custom middleware alternative. Done means an agreed design for reliable completion and error extension points, including latency and exception data, before implementation is scoped.

Written by the indexing model from the issue text.