Ship an AwesomeAssertions.Mockly flavour alongside the v7/v8 packages

## Motivation

FluentAssertions 8 changed its licensing model, and a large part of the .NET community moved to [AwesomeAssertions](https://github.com/AwesomeAssertions/AwesomeAssertions), an API-compatible fork. Those users can use Mockly, but they cannot use any of its assertions — they would have to pull in FluentAssertions purely for this package, which is exactly what they moved away from.

## Proposal

Ship a third flavour, e.g. `AwesomeAssertions.Mockly`.

The repository is already structured for this. There is one shared implementation file (`Shared/HttpMockAssertionExtensions.cs`), a `#if FA8` conditional for the API differences, and two near-identical csproj files that differ only in `DefineConstants` and the package reference. Adding a third target is mostly build plumbing plus a specs project and an approved-API file.

## Scope

- New `AwesomeAssertions.Mockly` project referencing `AwesomeAssertions` instead of `FluentAssertions`
- Reuse `Shared/HttpMockAssertionExtensions.cs` unchanged if possible; add a define if the API differs
- New specs project mirroring the existing v7/v8 specs
- New approved-API file, plus packaging and CI wiring

## Notes

- AwesomeAssertions tracks the FluentAssertions 7/8 API closely, so the existing `FA8`-style conditionals may already cover it.
- Worth deciding whether the shared file grows a second define or whether the flavours diverge.
- This is probably the largest reach-per-effort item in the repo: it unlocks the package for an entire user base at low marginal cost.

Start by comparing the existing v7/v8 project files, specs projects, approved-API files, and packaging or CI wiring. Read Shared/HttpMockAssertionExtensions.cs and run the existing specs to understand the shared assertions and API differences. Done means an AwesomeAssertions.Mockly package, matching specs and approved API, with packaging and CI coverage.

Written by the indexing model from the issue text.