Make implicitly dependent feature explicitly depend on each other

By running an invocation of cargo hack, we found a number of compile issues when using unusual feature combinations, and these are largely rectified by making intended feature pairings explicit.

New Feature Dependencies

[x] rustls-tls + openssl-tls now depend on client
[x] oauth + oidc + gzip + socks5 + http-proxy + unstable-client now depend on client
[x] unstable-runtime now depend on runtime

Testing Feasibility / cargo hack on CI

Because each feature basically doubles the amount of tests, we do actually need to restrict the input space from the raw powerset a bit. Without restrictions (skipping oidc + oauth mandatory), we get:

11370 feature combinations
>1h duration locally (my CPU sits mostly sitting idle in context switches)
generates >60G of artifacts in target

However, with grouping of commonly additive features, we can basically halve the number of tests per grouping. A moderately aggressive grouping of small client features (socks5 + http-proxy + gzip), smaller core features (admission + jsonpatch + derive) and client features (client + kubelet-debug) we get:

624 feature combinations
5m duration locally on a blank cache / 8m duration on GHA with cache
generates 6G of artifacts in target

So, kind of works on CI. Have included it as a test on main only (and this branch explicitly as a PoC).

Limitations

This is only testing feature combinations on the main interface crate kube.
oauth / oidc :: should depend on a tls stack but we cannot make that choice

We do have fallback compile_errors for oidc and oauth, but I have not found a way to tell hack to model this without just excluding them.

kube-rs / kube