feat(reachableservices): support defining reachable services for MeshService and MeshExternalService

[lukidzi]

Checklist prior to review

closes #10602
Impl #10737
Impl #10508
Solves #5041 for reachableBackends

This PR provides a way to define reachable services for MeshService and MeshExternalService. Also, it introduces a way to support auto reachable services for a MeshService.

• added new annotation kuma.io/reachable-backend-refs and dataplane field transparentProxying.rechableBackends.refs which allows providing definition of Mesh*Service reachable for a dataplane in a structured way
• In MeshContext I am building a map for labels to Mesh(service, so once the user defines that wants reach all services in a namespace k8s.kuma.io/namespace: demo can find all MeshServices that have this label (should we consider limiting allowed tags?)
• we add outbound based on backendRef and non backend ref, in the case of a cluster with MeshService and another without MeshService we add them based of existence of annotations
  • if reachableSevices present we don't add backend refs
  • if reachableBackends present we don't add kuma.io/services
• One case that not fully sure how to handle expressed by the test https://github.com/kumahq/kuma/pull/10869/files#diff-e5fd492c9fca43317e405258365acd5ac7b6c69f43186739de3919c00329e1deR333

• Link to relevant issue as well as docs and UI issues --
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS --
• Tests (Unit test, E2E tests, manual test on universal and k8s) --
  • Don't forget ci/ labels to run additional/fewer tests
• Do you need to update UPGRADE.md? --
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label) --

[Icarus9913]

Will there be a conflict once the annotation kuma.io/reachable-backend-refs and kuma.io/transparent-proxying-reachable-services are both used?
Or we have a priority with the 2 annotations or we can disallow this behavior in webhook?

[lukidzi]

Will there be a conflict once the annotation kuma.io/reachable-backend-refs and kuma.io/transparent-proxying-reachable-services are both used? Or we have a priority with the 2 annotations or we can disallow this behavior in webhook?

I think we can do following:

1. When only reachable-services or reachable-backends defined then use only one of them and do not include other
2. When both defined use both