Support client cert validation (spki, hash, san)

*Description*:
I'd like to allow a TLS handshake based on SNI and client certificate fields. For example, to allow only handshakes from a client with SAN URI `spiffe://example.com/client` to `server.example.com` service.

In the context of Envoy I need to configure [CertificateValidationContext](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto#extensions-transport-sockets-tls-v3-certificatevalidationcontext) in a corresponding listener's filter chain.

To achieve this goal I propose to add `spkiHashes`, `certificateHashes` and `subjectAltNames` fields to `ClientValidationContext` of `ClientTrafficPolicy`. For example:
```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
namespace: default
name: mtls-authentication
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: eg
sectionName: server
tls:
clientValidation:
caCertificateRefs:
- kind: Secret
name: root-ca
spkiHashes:
- NvqYIYSbgK2vCJpQhObf77vv+bQWtc5ek5RIOwPiC9A=
certificateHashes:
- df6ff72fe9116521268f6f2dd4966f51df479883fe7037b39f75916ac3049d1a
subjectAltNames:
dnsNames:
- { type: Exact, value: client.example.com }
emailAddresses:
- { type: Suffix, value: @example.com }
ipAddresses:
- { type: Prefix, value: 192.168. }
uris:
- { value: spiffe://example.com/client }
otherNames:
- { oid: 1.3.6.1.4.1.311.20.2.3, value: client }
```

An alternative would be to introduce a new type of [Principal](https://gateway.envoyproxy.io/docs/api/extension_types/#principal) to `AuthorizationRule` of `SecurityPolicy`.
But we can only support `Allow` action (there are only allowlists in Envoy's CertificateValidationContext) on a Gateway target (because it affects all routes) and return an error otherwise. Additionally [SecurityPolicy doesn't support sectionName](https://github.com/envoyproxy/gateway/blob/v1.4.0-rc.2/api/v1alpha1/securitypolicy_types.go#L43), so for now it's not possible to attach a policy to a specific listener and propagate rules to the right filter chain. PR https://github.com/envoyproxy/gateway/pull/5916 fixes it.

I would also add that there are four places where we can validate SANs in Envoy: CertificateValidationContext, network RBAC filter, HTTP RBAC filter and per route RBAC filter. It may be a good idea to support configuring:
- CertificateValidationContext with ClientTrafficPolicy (allows to deny a connection at handshake stage)
- network RBAC filter with SecurityPolicy attached to a Gateway (allows to define blocklists in addition to allowlists)
- per route RBAC filter with SecurityPolicy attached to a route (granular control after TLS termination and an app protocol parsing)

So ClientTrafficPolicy and SecurityPolicy could complement each other. And I think ClientTrafficPolicy is a good place for adding SPKI hashes, certificate hashes and SANs to validate inbound TLS connection at handshake stage.

*Relevant Links*:
- an implementation based on `ClientTrafficPolicy` https://github.com/envoyproxy/gateway/pull/5868