Closes coder/internal#780

Summary of changes:

• added user_secrets table
  • user_secrets table contains env_name and file_path fields which are not used at the moment, but will be used in later PRs
  • user_secrets table doesn't contain value_key_id, I will add it in a separate migration in a dbcrypt PR
  • on one hand I don't want to add fields which are not used (because it's a risk smth may change in implementation later), on the other hand I don't want to add too many migrations for user secrets table
• added unique sql indexes
• added sql queries for CRUD operations on user-secrets
• introduced new ResourceUserSecret resource
• basic unit-tests for CRUD ops and authorization behavior
• Role updates:
  • owner:
    • remove ResourceUserSecret from site-wide perms
    • add ResourceUserSecret to user-wide perms
  • orgAdmin
    • remove ResourceUserSecret from org-wide perms; seems it's not strictly required, because ResourceUserSecret is not tied to organization in dbauthz wrappers?
  • memberRole
    • no need to change memberRole because it implicitly has access to user-secrets thanks to the allPermsExcept
  • is it enough changes to roles?

Main questions:

• We will have 2 migrations for user-secrets:
  • initial migration (in current PR)
  • adding value_key_id in dbcrypt PR
  • is this approach reasonable?
• Are changes to roles's permissions are correct?
• Are changes in roles_test.go are correct?