Unify & upstream our code for profile_list differentiation

[yuvipanda]

We currently have code that allows us to show people different profile list options based on some notion of group membership. The initial implementation was tied to GitHub teams membership, and hence not upstreamable into KubeSpawner (where the profile_list code lives). However, with #3883, we have a version of that code that uses JupyterHub groups, and hence is now actually upstreamable.

Unifying this code and upstreaming it allows us to maintain fewer things. There's no real rush, but it's useful to make sure that whatever we do is done with an eye to upstreaming. To that end, I've already been slowly working on things that can help make this happen. Here's a linear set of items that we can do to help.

• Get Allow restricting profiles & profile_options based on JupyterHub groups #3883 deployed
• Get [All] Move group management from generic to base oauthenticator (allowed_groups, admin_groups, auth_state_groups_key) jupyterhub/oauthenticator#735 merged
• Once [All] Move group management from generic to base oauthenticator (allowed_groups, admin_groups, auth_state_groups_key) jupyterhub/oauthenticator#735 is merged, setup our hubs to turn GitHub team membership into JupyterHub groups. This motivating use case is driving the design of the PR forward.
• From this point on, new hubs can simply use allowed_groups, and allowed_teams can be considered legacy.
• Upstream the allowed_groups code into kubespawner.
• Migrate existing hubs from allowed_teams to allowed_groups via some strategy (slowly, one every sprint, or quickly, in one go). It requires everyone to re-login so group membership is properly set up
• Rip out the allowed_groups code
• Pat ourselves on the back.

The timeline for this is 'slowly, over months'.