Add gov API version 2024-07-01

[eddyashton]

See #6280. The contents and behaviour of this api-version are identical to 2023-06-01-preview, but since we've proved out the new API we're now marking it non-preview.

Opening this as draft as there are still a few blockers:

• Adding to CHANGELOG
• Updating docs
• Clearing Track discrepancies between versioned governance API spec and implementation #5691. Little to do here but wait for upstream approval, but don't want to take risk of merging this early and then needing to patch EDIT - Bored of waiting for upstream, so we're just skipping ahead and pulling the presumed changes in this PR.

[eddyashton]

This PR now includes a few additional changes, with a view to closing #5691 as well as introducing the new API version, which I'll try to summarise here:

• Pull the latest (generated from TypeSpec) OpenAPI document for the 2023-06-01-preview API version. Essentially this just means the OpenAPI document (stored in our repo, returned from GET /gov/api?api-version=2023-06-01-preview) now matches the implementation (as much as possible), including fixing all of the discrepancies described in Track discrepancies between versioned governance API spec and implementation #5691.
• Renames these files (including example requests/responses) for clarity - here they're the gov API, not mccf.
• Pulls a (generated from TypeSpec) OpenAPI document describing the 2024-07-01 API version. This isn't a great situation - the source lives on a branch on my fork for now (https://github.com/eddyashton/azure-rest-api-specs/tree/ccf_gov_2024_07_01/specification/confidentialledger/Microsoft.ManagedCcf), and is manually exported. Eventually we need to decide if we stay TypeSpec-first for this API (and bear the cost of a TypeSpec toolchain dependency), or abandon this and go source-first again. The current solution is a temporary bandaid.
• Adds 2 new APIs for accessing JS modules, to resolve Need modern API equivalent of the classic gov/kv/modules API #6117, only available with this newest API. Really just an opportunity to test the API versioning machinery, that we can safely introduce new APIs.
• Extend our api_version_adapter wrapper to support a minimum accepted version, for newly introduced APIs.
• Some additional tests for the new endpoints.