Fix handling of generic resource in the kubernetes deployer

[iocanel]

Resolves: #19379
The pull request adds handling for generic resources in the KubernetesDeployer.

This is done by querying the api server for information based on the generic APIResource.
Then it uses the information in order to construct the generic url etc.
This is aligned with how kubectl handles unknown resources.

[gsmet]

@iocanel any chance this could be finalized before I release 2.7.0.Final (i.e. before Tuesday evening)?

[metacosm]

So the whole point is to figure out whether the resource is namespaced and what its plural is? Would it make sense to first try the operation with some assumptions (i.e. that the resource is namespaced and what its plural is (using fabric8's Pluralize) and only query the cluster for the information if that failed? Or we could even try twice: once namespaced, once cluster and finally query the cluster if it still doesn't work?
Not sure what's the cluster impact performance-wise of enumerating all resources…
LGTM otherwise.

[manusa]

This logic is already present in the client:

https://github.com/fabric8io/kubernetes-client/blob/7ef49cd34e2de0d68422e17ce24fe15e48b63f17/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/Handlers.java#L83

It can be reused by using client#resources(Class<T> resourceType, Class<L> listClass) or client#genericKubernetesResources(String apiVersion, String kind)

I'm not sure if you are aware of this.