[API Proposal]: Add DI / ASP.NET Core integration (AddMocklyHandler, WebApplicationFactory support)

## Motivation

Today `HttpMock` can only hand a client *out*: `GetClient()`, `GetClientFactory()` and `GetMessageHandler()`. There is no supported way to push the mock *into* an existing DI container.

That makes the most common integration-test scenario awkward. If the system under test resolves a typed client through `IHttpClientFactory`, or lives behind a `WebApplicationFactory`, you have to hand-roll handler replacement yourself.

## Proposed API

A separate package (e.g. `Mockly.Extensions.Http`) so the core package stays dependency-free and `net472`-friendly:

```csharp
// Replace the primary handler of a single named or typed client
services.AddHttpClient().AddMocklyHandler(mock);
services.AddHttpClient("github").AddMocklyHandler(mock);

// Replace the primary handler of every registered client
services.AddMockly(mock);

// ASP.NET Core integration tests
var factory = new WebApplicationFactory().WithMockly(mock);
```

## Notes

- Should keep any `DelegatingHandler`s registered by the application in place, so resilience/retry pipelines (`Microsoft.Extensions.Http.Resilience`, Polly) are still exercised. Only the *primary* handler is swapped.
- Needs to work with both typed and named clients.
- Belongs in a separate package: it takes a dependency on `Microsoft.Extensions.Http` (and optionally `Microsoft.AspNetCore.Mvc.Testing`), neither of which should leak into the core package.

Start by reviewing the existing HttpMock APIs named in the proposal—GetClient(), GetClientFactory(), and GetMessageHandler()—and the core package dependency boundaries. Done means a separate integration package supports named and typed clients plus WebApplicationFactory, while preserving registered DelegatingHandlers and keeping the core package dependency-free.

Written by the indexing model from the issue text.