Revisit root permissions and entrypoint for user management

In start.sh, we support setting up the user in a variety of ways that currently require the container to be started as root. #552, #553, #559 introduce a mechanism to handle a subset of those cases when the user is in the root *group*, as is typical with openshift. #553 initially did so in an ENTRYPOINT instead of CMD in order to benefit even when CMD is overridden, e.g. directly to `jupyterhub-singleuser` in kubespawner. That logic now resides in start.sh with everything else (#559), but perhaps much of start.sh ought to move to an ENTRYPOINT instead of the CMD.

Things to consider:

1. how much can/should we accomplish with the root *group* instead of the root *user*? I'd love it if we could stop requiring folks to launch the image as the root user, since a slip-up there can be a major permission issue
2. how much of the permissions/user setup belongs in an ENTRYPOINT rather than start.sh? Pro of ENTRYPOINT is that overriding CMD preserves permissions/user-management logic. Con of ENTRYPOINT is that opting out of user-management behavior is a bit harder if desired. So if we move things to the entrypoint, we should make sure that default behavior is always safe and almost always desirable.

Current capabilities in start.sh that require root permissions:

- update $HOME to /home/$NB_USER if username is set specifically
- rename `jovyan` user to `$NB_USER` if set
- set UID/GID of NB_USER
- grant $NB_USER sudo permissions
- chown $HOME (typically just the empty-directory volume case)

Start with start.sh and the current container ENTRYPOINT/CMD behavior, then review issues #552, #553, and #559 for the existing root-group handling. Trace each listed user and permission operation and determine which behavior should remain safe when CMD is overridden. Done requires an agreed design for root-user versus root-group support and the placement or opt-out behavior of user management.

Written by the indexing model from the issue text.