Restore bearer-token fallback in Configuration.auth_settings()

Prior to v36.0.0 the generated client stored the bearer token under
api_key['authorization']. v36.0.0 switched the lookup to
api_key['BearerToken'] without a fallback, which silently dropped the
Authorization header from every outgoing request when callers (or the
load_kube_config path in v36.0.0) still wrote the token under
'authorization'. The result was 401 Unauthorized against every cluster
that relied on bearer-token auth, observable on both REST calls and
WebSocket exec.

Restore the legacy lookup as a fallback in auth_settings(): if
'BearerToken' is absent but 'authorization' is set, route the lookup
through get_api_key_with_prefix(..., alias='authorization') so the
existing 'authorization' key is honored. 'BearerToken' continues to
take precedence when both are set, so the new behavior is unchanged
for new code.

Applies symmetrically to kubernetes.client.configuration and
kubernetes.aio.client.configuration.

Related issue: https://github.com/kubernetes-client/python/issues/2595

Signed-off-by: Gaurav Galiyawala <galiyawalagaurav@gmail.com>