Refine what is possible via withRequestConfig

[shawkins]

The RequestConfig object exposes quite a few timeouts, authentication properties, and other things that we are allowing to be set on a per request basis if one starts with NamespacedKubernetesClient.withRequestConfig.

There are several issues with this:

• in the code it's effectively part of the Config, which is otherwise immutable. That is confusing to deal with and requires extra logic to pass around to the interceptors.
• passing alternative authentication is confusing to the logic in the interceptors. Although that may be improved by fix #4698: refining authentication mechanisms to be clearer #4702.

It would be good to re-assess what about this feature is actually needed, and if it should just be part of the regular dsl - that is instead of client.adapt(NamespacedKubernetesClient.class).withRequestConfig(new RequestConfigBuilder().withImpersonateUsername("name").build()).(c -> ...)

should we just offer

client.withImpersonateUsername("name")...

With methods for whatever seems still useful.

[shawkins]

The alternative to

client.adapt(NamespacedKubernetesClient.class).withRequestConfig(new RequestConfigBuilder().withImpersonateUsername("name").build()).(c -> ...)

is currently how it's implemented under the covers

client.newClient(new RequestConfigBuilder().withImpersonateUsername("name").build()).adapt(KubernetesClient.class)

The javadocs are incorrect for the newClient method - I'll correct that as part of this issue. It no longer needs to create a fully new instance now that we are passing the augmented requestconfig into the interceptors.