Fixes #930.

Description

This pull request adds a User table to the database with the intent of replacing the NamespaceRoleMapping system for managing user permissions.

• Formally defined a Role enum type to replace current role permissioning in conda-store. Users can have different roles for different environments: NONE (no access to environment), VIEWER (can view an environment), EDITOR (can edit an environment), and ADMIN (administrator for an environment). Integer access levels are also assigned to each of these, with higher values representing greater levels of access; this allows you to do comparisons like Role.EDITOR < Role.ADMIN.
• User and RoleBinding tables added to database. Each User has zero or more associated entries on the RoleBinding table which define the level of permissions the User has for each environment. When a new user is created, the role bindings passed to conda-store get translated into entries in the RoleBinding table, which stores the pattern for each role binding. For example if a user is created with the following role bindings:

role_bindings = {
    'env*/foo': {'viewer'},
    'home/*': {'editor'},
}

This will produce two rows in the RoleBinding row: one with RoleBinding.role == Role.VIEWER and another with RoleBinding.role == Role.EDITOR. The first row matches any environment named foo in any namespace starting with env, and the other matches any environment in the home namespace.

• Added documentation in the alembic readme about how to generate database migrations for conda-store, since there was none.
• Fixed a bug in script.py.mako that would cause new autogenerated migrations to fail
• New User entries (and associated RoleBinding entries are created when the user sends a successful POST to /login/. schema.AuthenticationToken has been updated to include a user_name key for use by conda-store. No password is stored currently.

Note this will require changes for Nebari to pass usernames for the users as part of the token to conda-store.

To do

• Generate User and RoleBinding tables
• Generate database migration
• Add user_name field to schema.AuthenticationToken so that conda-store can distinguish users. Keycloak will need to do this too!
• Upon login, check if the user is in the db; if not, add the user with the correct permissions
• Update conda_store_server.api.list_environments

Pull request checklist

• Did you test this change locally?
• Did you update the documentation (if required)?
• Did you add/update relevant tests for this change (if required)?