OAuth 2.1

### Describe the feature

This is less a feature request than an attempt to gather feedback and opinions on OAuth 2.1 support in Vert.x see the [OAuth 2.1 draft](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1).

OAuth 2.1 consolidates the OAuth 2.0 core into a single, modernized document folding in PKCE, dropping the implicit and password grants, and mandating current security best practices. Around that core sits a family of widely deployed extension RFCs:

- [RFC7009](https://www.rfc-editor.org/info/rfc7009) - Token Revocation
- [RFC7591](https://www.rfc-editor.org/info/rfc7591) - Dynamic Client Registration
- [RFC7662](https://www.rfc-editor.org/info/rfc7662) - Token Introspection
- [RFC8414](https://www.rfc-editor.org/info/rfc8414) - Authorization Server Metadata
- [RFC8628](https://www.rfc-editor.org/info/rfc8628) - Device Authorization Grant
- [RFC8705](https://www.rfc-editor.org/info/rfc8705) - Mutual TLS
- [RFC8707](https://www.rfc-editor.org/info/rfc8707) - Resource Indicators
- [RFC9068](https://www.rfc-editor.org/info/rfc9068) - JWT Profile for OAuth 2.0 Access Tokens
- [RFC9126](https://www.rfc-editor.org/info/rfc9126) - Pushed Authorization Requests
- [RFC9207](https://www.rfc-editor.org/info/rfc9207) - Authorization Server Issuer Identification
- [RFC9396](https://www.rfc-editor.org/info/rfc9396) - Rich Authorization Requests
- [RFC9449](https://www.rfc-editor.org/info/rfc9449) - Demonstrating Proof of Possession (DPoP)
- [RFC9470](https://www.rfc-editor.org/info/rfc9470) - Step-Up Authentication Challenge Protocol

Today vertx-auth-oauth2 only covers the OAuth2 client side. What I'd like to see is at least a foundation people can build their own auth on ideally with some ready-to-use pieces (e.g. a resource server implementation), or at minimum composable building blocks so users can assemble exactly the subset of OAuth 2.1 they need rather than pulling in everything.

For example: the Model Context Protocol [authorization spec](https://modelcontextprotocol.io/specification/draft/basic/authorization) requires/recommends RFC8414, RFC7591, and RFC8707 (plus [RFC9728](https://www.rfc-editor.org/info/rfc9728) Protected Resource Metadata). None of that is available out of the box in Vert.x today, so anyone securing an MCP server has to implement it themselves.

I think with work going on in vertx-grpc this could start making sence as really easy way for people to just drop and forget authorization, insteda of having to rely on their own implmentatitons.

For prior art, Spring Security splits this cleanly into two modules a resource server and an authorization server:

- https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/index.html
- https://docs.spring.io/spring-security/reference/servlet/oauth2/authorization-server/index.html

I'm interested in what people think whether this belongs in vertx-auth or in vertx in general, what scope would make sense, and what would be potentionally ideal way to do this.

### Contribution

_No response_