Support team clusters

I think we should have semi-persistent "team" clusters that can last longer than default ones (but are still periodically flushed and reprovisioned) and also have a workflow where the creds can be easily shared among a team.

Even among the team, there'd still be an "owner" who might be e.g. actively testing their operator, but they'd be able to release it and e.g. turn back on the CVO and leave things hopefully a in a clean state for the next user. Or, commonly two members of a team might be concurrently working on a PR.

Another (quite common for me) use case is "I just want to run some read-only commands (as kube:admin) against a recent-ish 4.6 cluster".

Setup:

• A team is defined as one of the github team aliases we have today, e.g. @openshift/openshift-team-red-hat-coreos
• We synchronize membership of the GH team to Slack groups

UX, talking to @cluster-bot

<user> teamcluster request
<bot> cluster https://console.team-redhat-coreos.devcluster.openshift.com/ is currently available
<bot> (kubeconfig attachment)
<bot> use `teamcluster done` when you're done

Scenario where cluster is in use:

<user> teamcluster request
<bot> cluster https://console.team-redhat-coreos.devcluster.openshift.com/ is in use by @miabbott
<bot> use `teamcluster ping` to send a message to @miabbott requesting current credentials
<user> teamcluster ping

Bot to @miabbott:

<bot> user @cgwalters has requested access, reply "yes" to grant, "no <reason>" to indicate refusal
<miabbott> <yes or no>

Alternative flow for immediate grant of "readonly" access:

<user> teamcluster request ro
<bot> cluster https://console.team-redhat-coreos.devcluster.openshift.com/ is in use by @miabbott
<bot> (kubeconfig attachment)
<bot> You requested read-only access, please avoid changing the cluster

(Bot also ends a message to @miabbott like: <bot> User @cgwalters requested readonly access)

Start with the proposed @cluster-bot workflows and the existing GitHub team aliases and Slack group synchronization described in the issue. Define the team-cluster lifecycle, ownership and handoff behavior, credential-sharing and read-only access rules, then confirm that the request, ping, done, and periodic reprovisioning flows are specified before implementation.