fix(gateway-api): verify TLS/TCPRoute is accepted before pushing to Gateway

[czeslavo]

What this PR does / why we need it:

Fixes lack of verifying if TLS/TCPRoutes are accepted by the Gateway before proceeding with provisioning. It effectively enables GEP-957 port matching for them -- without that even when a Route doesn't match any Listener, it will be provisioned in Kong Gateway, which is incorrect.

It also improves populating ListenerStatus.SupportedKinds by deriving kinds from listener's protocol or AllowedRoutes.Kinds.

Which issue this PR fixes:

Part of #2709.

Special notes for your reviewer:

UDPRoute is left with no modifications due to a lack of possibility to specify two separate publish services for TCP and UDP (see #2544), which is blocking passing the existing integration tests. The default "publish service" (ingress-controller-kong-proxy LoadBalancer) exposes all its ports as TCP ones (including the 9999 which is meant to be UDP). Due to that, it falls into this case where Listener is marked as not ready due to a missing UDP port.

We may decide to:

• fix that before the 2.8 release by implementing Publish service does not account for separate TCP and UDP LBs #2544 and adapting UDPRoute tests to use ingress-controller-kong-udp LoadBalancer as its Unmanaged Gateway publish service,
• postpone fixing UDPRoute to the next release.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[pmalek]

As for the UDP issue: I'm personally in favor of postponing this (unless we have a strong desire to include this in 2.8). Reason being that the fix might take some time and be more involved (although I can be convinced otherwise).

[czeslavo]

As for the UDP issue: I'm personally in favor of postponing this (unless we have a strong desire to include this in 2.8). Reason being that the fix might take some time and be more involved (although I can be convinced otherwise).

Yup, I also think that will be the most reasonable approach. Adding the UDP publish service, adapting helm charts for that and testing properly might take some time.