EnvoyPatchPolicy + Merged Gateways - docs perhaps need improvement ?

This came up when I was trying to find a way to [disable timeouts on `GRPCRoute` objects, to support long-lived GRPC streams](https://github.com/envoyproxy/gateway/issues/5446). `EnvoyPatchPolicy` objects offer a way to directly patch xDS resources, so they looked like a potential short-term solution until this feature is added in by Envoy Gateway.

However, in an environment with **merged** Gateways, this specific use case does not actually work with `EnvoyPatchPolicies`. This is because:

- To make a patch work for this use case, you'll need to point it at a `type.googleapis.com/envoy.config.route.v3.RouteConfiguration` xDS resource
- In an environment with merged Gateways, **listeners of the same protocol and port get grouped up together under one `RouteConfiguration`**
- As a result, if your environment has e.g. `10` Gateways, the `RouteConfiguration` xDS resource will only be created for the very first Gateway, and all others become `virtual_host` entries underneath it.
- As a result, in order to work,the `EnvoyPatchPolicy` needs to target a `RouteConfiguration` that in fact belongs to another `Gateway` object - which could change / get renamed / get deleted at any time.

Granted, `EnvoyPatchPolicy` comes with a set of caveats that the docs include, and its purpose as a temporary workaround-tool is well understood. I do still think it would be really great to have the docs updated to be more specific, especially if there are (more of?) such cases where the way Envoy Gateway is configured can make patches unusable.

Unfortunately I don't know the interiors of Envoy well enough to say whether that's the case. I'd be happy to update the docs on this specific scenario, but I feel like this area could use the eyes and 🧠 of someone more knowledgeable on the topic 😄