TLSRoute/HTTPRoute multiplexing

**What would you like to be added**:
As a cluster admin, I want my Gateway to support, on a single port, different types of routes. As an example, I want the following to be possible:
```yaml
listeners:
- name: somelistener
port: 443
protocol: TLS
hostname: "*.example.tld"
tls:
mode: Passthrough
- name: httpslistener
port: 443
protocol: HTTPS
hostname: "*.anotherexample.tld"
tls:
mode: Terminate
certificateRefs: ...
```

With the specification above, any request to hostnames on `*.example.tld` should be attached to `TLSRoutes` while requests to `*.anotherexample.tld` are terminated on the `Gateway` and attached to a `HTTPRoute`.

The support for Multiplexing on TLS is to be decided between `Extended` or `ImplementationSpecific`, and implementations that support this feature MUST announce it on `GatewayClass.Status.SupportedFeatures`.

Implementations that don't support multiplexing SHOULD mark the violating listeners with a Condition `Conflicted=True`.

This means that, based on the hostname attribute from a Gateway, I want to select TLSRoute or HTTPRoute and do the proper routing.

**Why this is needed**:
Supporting Passthrough and non passthrough on the same port is desired. While we can do this with mixed Termination/Passthrough on the listener tls mode, this still disallows us of setting specific rules, filters and matchers on a HTTPRoute as the routing is restricted to TLSRoute, that doesn't have many attributes.

With multiplexing, I can rely on a single gateway for my network, lowering my costs and my management toil while allowing my users to specify the behavior they want.

=====
Some previous art removed from the original TLSRoute GEP:

### Requested flow

In the case of TLSRoute + HTTPs multiplexing, it should operate similarly to the mixed TLSRoute, but instead of decrypting and passing the TCP connection as is to the backend, the proper HTTPRoute workflow should happen.

### Conflict management

* When a Gateway supports [Multiplexing](#multiplexing-support) it CAN allow multiple listeners on the same port, as soon as they do not conflict on `hostnames` and `tls.mode`.
* When a Gateway does not support [Multiplexing](#multiplexing-support) and contains a listener with `protocol=TLS`, the Gateway MUST NOT allow any other kind of listener on the same port, and any violating Listener should have a Condition `OverlappingTLSConfig=True` with the reason `OverlappingProtocols`.

Conformance tests
| A Gateway containing a Listener of type TLS/Passthrough and a Listener of type HTTPS/Terminate should be accepted, and should multiplex the requests to TLSRoute and HTTPRoute correctly | Being able to do a request to a HTTP route being terminated on gateway (eg.: terminated.example.tld/xpto) and to a TLS Passthrough route on the same gateway, but different host (passthrough.example.tld) | |

* [TLS Multiplexing issue discussion](https://github.com/kubernetes-sigs/gateway-api/issues/623)

Start with the TLS Multiplexing issue discussion at issue 623 and the conformance-test scenario described here. Define how TLS/Passthrough and HTTPS/Terminate listeners on one port are represented, including SupportedFeatures and conflict conditions. Done means the behavior and conformance expectations are specified clearly enough for implementations to route TLSRoute and HTTPRoute traffic by hostname.

Written by the indexing model from the issue text.