Implement Listener Hostnames and associated TLS mode on matching TLSRoutes

[rainest]

Listener includes an optional core Hostname field. When present, Routes must have a hostname set that intersects with the Listener hostname (cardinality 1) set to associate with that Listener.

Because the TLS mode is set by Listener.TLS association with a specific Listener is the only way to specify a TLS mode (terminate or passthrough). We must use parentRefs to set the Kong route protocol (ignoring the hack method of setting it using the protocol annotation).

This probably requires some review of how we determine which Listener to match and what we do if there is ambiguity about which Listener matches. There's probably some stuff in the spec that clarifies how that sorts out and/or what ambiguities are impermissible.

Per conversation with other Gateway API implementers, Listeners permitting only a single Hostname is by design, because matching logic gets way overcomplicated otherwise. While a single match is sufficient, I think this may raise some confusing situations where a single TLSRoute matches multiple Listeners that specify different configurations, e.g. I think it's valid to have:

TLSRoute.Hostnames: foo.example, bar.example, baz.example

ListenerA: Hostname=foo.example, TLS.Mode=Terminate
ListenerB: Hostname=bar.example, TLS.Mode=Passthrough

If that is permitted by the spec (again, need to read it more closely to be certain), which routes do we create? Relevant spec language states that:

• "It is valid to reference multiple distinct sections within the same parent resource, such as 2 Listeners within a Gateway." from CommonRouteSpec.
• "If both the Listener and TLSRoute have specified hostnames, any TLSRoute hostnames that do not match the Listener hostname MUST be ignored." from TLSRoute.Hostname.

This suggests that we should create separate routes for foo.example and bar.example, and do nothing for baz.example. I'm not sure then whether we indicate that the TLSRoute is only partially available (and if so, how) or if we reject it altogether.

[rainest]

#2555 handles the Listener/Hostname stuff and various different types of conflicts. It does not handle TLS mode, which has moved to #2662