Add more capabilities to certificate-matcher for mTLS routes

[calderonth]

Is your feature request related to a problem? Please describe.
Currently the Certificate Matcher that can be configured in a route when using mTLS only offers the following capabilities:

• fingerprint (SHA256)
• spki_hash

This is insufficient and not scalable when configuring policies. Instead, one would expect the certificate matcher to allow a lot more granulatity, such as filtering on the SANs and using complex expression to build better mTLS route-logic.
In addition, when a route matches on mTLS, there is nothing in the JWT assertion to indicate that this is what allowed the connection to get through, instead one has to add custom HTTP header that can only include the fingerprint of the certificate.
It would be interesting to add claims to the JWT token to indicate reference the "method" that was used to authenticate (user, bearer, mtls certificate) and carry more metadata.

Describe the solution you'd like
The ability to build better mTLS route ACL using more complex matching, for instance:

- client_certificate:
    match_subject_alt_names:
      - email: '.*@blah\.com'

Describe alternatives you've considered
I have tried using the global SAN matching but it seems a little buggy.
I have reported #4614 on the side of this feature request.

[desimone]

FYI, working on a corporate CLA.