[ENH] - Add User object to database

[peytondmurray]

Feature description

Currently, conda-store doesn't have the concept of a User. This leads to much confusion among
conda-store users and devs because:

1. When you run docker compose up --build to bring up conda-store locally and then navigate to
   https://localhost:8080, you are presented with a login screen, suggesting that you need user
   credentials
2. When you use nebari, you have to login with keycloak
3. conda-store has a robust permissioning system

In actuality, conda-store doesn't store user credentials at all. Nebari users login with keycloak,
which then mints a token that contains a user's role bindings for conda-store; then every request
sent to conda-store-server includes this token, which conda-store processes and uses to know
what environments/namespaces are available to the person who made the web request.

The effect of this choice is that we don't have to manage user credentials or keep track of users,
but at the cost of a lot of internal code complexity and developer confusion.

This issue is to start the discussion about adding a User table to the database. Potential issues:

• Coordination with Nebari team to prevent breaking active deployments
• Ensuring conda-store authentication works with Keycloak authentication

Other notes

Currently, we are managing Roles using just python strings; i.e. there's no Role enum defined anywhere. In any context where we need to enforce a certain level of access, we do string comparison to figure out whether someone has the required role bindings to do the action.

Additionally we have an Enum class for Permissions, which are used for restricting access for certain conda-store actions, e.g. environment::create.

Value and/or benefit

• Reduction in developer confusion
• More straightforward code paths any time we need to get role mappings for a user

Key Workflows

A working implementation must

• Define User, Role, and Permission tables
• Allow each User to have admin, viewer, or editor Role for various namespace/environment rules.
• Map each Role to Permission entries; e.g. a User with the editor Role for namespace/environment */foo, should be able to create or edit environments named foo in any namespace.