[Epic] ASP.NET Core ❤️ Debugging

**This issue has evolved into an epic for making debugging better across ASP.NET Core**

There are two primary areas we want to hit:

Debugging HTTP requests. This means `HttpContext` and friends are easily debuggable.

- [x] `HttpContext` and friends (this issue)
- [x] `Endpoint`/endpoint metadata https://github.com/dotnet/aspnetcore/issues/39792
- [x] `ClaimsPrincipal` https://github.com/dotnet/runtime/issues/86421

Debugging hosting. Give feedback about whether a host is running, its name, and its environment (i.e. Production vs Development).

- [x] `IHost` and related types https://github.com/dotnet/runtime/pull/88308

Debugging application startup. I think there is **a lot** that could be done here. ASP.NET Core has a lot of configuration settings, and we should figure out where to focus energy to provide the best value.

- [ ] `WebApplicationBuilder` and friends
- [x] `WebApplication` and friends https://github.com/dotnet/aspnetcore/pull/48827
- [x] Microsoft.Extensions.Configuration https://github.com/dotnet/runtime/issues/86550
- [x] Microsoft.Extensions.DependencyInjection https://github.com/dotnet/runtime/issues/86553
- [x] Microsoft.Extensions.Logging https://github.com/dotnet/runtime/pull/88313 https://github.com/dotnet/runtime/pull/87754

Debugging connections. This would be the `ConnectionContext` that is available in connection middleware and Kestrel transports. Lesser used area.

- [ ] `ConnectionContext`, `MultiplexConnectionContext`

---

### 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.

It's very common to debug HTTP requests in an ASP.NET Core app. For example, you want to check the client has sent the request you expect. What are the request headers? Query string? Form values? Cookies? Or you want to check the response. Has the response started? What is the status code? etc.

This is what `HttpContext` looks like today when debugging in VS:


It's not horrible. But it's not great.

In this result you can see that `CancellationToken` uses debugger display attribute to display at a glance whether the token is canceled or not. That's a great use of customizing .NET debugging.

Wouldn't it be useful if the other properties on `HttpContext` were just as informative? For example, the collections here and on request and response told you their counts: `Cookies Count = 1`. Or the connection property displayed the connection's local and remote addresses. Or the request property displayed the request method and URL.

We have the tools and technology to make it better:
* `DebuggerDisplayAttribute`
* `DebuggerTypeProxyAttribute`

### Describe the solution you'd like

Let's make a concerted effort to improve debugging `HttpContext` with debugging attributes.

Collections:
* Debugger display attributes that shows item count: `[DebuggerDisplay("Count = {Count}")]`
* Debugger type proxy to make viewing collection contents easier

Objects:
* Debugger display attributes that shows a summary of the object. For example:
* HttpRequest: Method and URL.
* HttpResponse: HasStarted and StatusCode
* Connection: Local and remote addresses

### Additional context

_No response_