Discover Kube targets by Endpoints, not Services

[andrewazores]

Fixes #282

This basically duplicates the existing OpenShiftPlatformClient implementation for reuse as the KubeApiPlatformClient. These use two different client libraries for the internal API clients, which also means different library implementations for the various Kubernetes types (Endpoints, Subsets, Ports, etc.). So although these types model the same Kubernetes datatypes, the types themselves are distinct hierarchies, and so the final concrete PlatformClient implementations are also distinct and do not inherit from each other (unfortunately).

This can be tested by setting the CONTAINER_JFR_PLATFORM env var to force the KubeApiPlatformClient into use and then running as usual in CRC. This should result in essentially no noticeable difference from running with the standard OpenShiftPlatformClient. Compared to the previous KubeApiPlatformClient implementation, only ports named jfr-jmx or numbered 9091 should cause ServiceRefs to be listed in the targets list. If a single Service has more than one such port, or if there are multiple Pods (each distinguished by cluster-internal IP address) behind the Service, then there should be near-duplicate ServiceRefs for each of these, differentiated by port number or by IP address.

[ebaron]

Looks good and works as advertised!