[RFE] oc CLI should preserve name of contexts

When working with OpenShift, it might happen that you connect to multiple clusters. These can be cloud clusters, on-premises, or even multiple profiles of minishift.
When you connect to a cluster, oc creates an entry for that context including cluster, user and namespace. These contexts that are created are given an automatic name by oc.

e.g.

default/console-cluster02-gce-pixy-io:8443/admin
default/127-0-0-1:8443/system:admin
devconfcz18/api-pro-us-east-1-openshift-com:443/jmorales@redhat.com

These names are difficult to handle and remember.

Kubernetes does promote giving these contexts a meaningful name in their documentation. But when you follow those practices in OpenShift, you run into many issues, which are what this issue/RFE wants to solve.

• Login into an openshift cluster via "oc login" creates entries in .kube/config even if they exist with different name
• "oc new-project" creates entries in .kube/config even if they exist with different name instead of just changing the current context's namespace
• "oc project" creates entries in .kube/config even if they exist with different name instead of just changing the current context's namespace
• "oc delete project" does not remove the namespace from the current context's context (or set a default)
• "oc logout" does not unset the "current-context" but only remove the token.

There's probably other things that make "oc" misbehave with respect to keeping a sane .kube/config file.

There's references in k8s to make enhancements on the usability:

• https://github.com/kubernetes/kubernetes/issues/40968

As well as references in other projects of the problem I described:

• https://github.com/minishift/minishift/issues/1915
• https://github.com/minishift/minishift/issues/1917

This RFE is to fix the behavior the "oc" client has with respect to using/interacting with .kube/config file.

Start by tracing how oc login, new-project, project, delete project, and logout read and write .kube/config, then compare that behavior with the referenced Kubernetes context guidance. Done means the CLI preserves meaningful existing context names and handles namespace and current-context changes consistently without creating avoidable duplicate entries.