Implement initial generalized collections in the backend

[fhennig]

Open questions:

• Should we store variant queries as JSON or in columns?
• The mutation list should also be combined with a lineage filter. But in theory we can have multiple lineage fields defined. Maybe this is a good reason to just store stuff as JSON.
• Which fields exactly should be allowed in the advanced queries, and which not? Is this filtering something we want to do in this issue, or move into a separate issue?
• Should we have a variant type for 'range' of mutations? Would be good for resistance mutations.

variant specs:

• mutation list with lineage filter
• variant query, with optional coverage query

Should we have a DB column in the variant table that stores whether this variant has a coverage query or not? For mutation lists, we could infer a coverage query easily.

---

We need:

• New tables
  • A new collections table:
    • collection_id (uuid)
    • name (str)
    • owned_by (user ID)
    • organism (str)
    • description (str)
  • A new variants table:
    • variant_id
    • collection_id
    • variant_type (query, mutationList, ...?)
    • (Either a JSON blob or multiple columns from which we assemble the different types.)
• Exposed mapping for the tables
• A collections model
• A new CollectionsController with endpoints to read and edit collections
  • Very similar API design to the subscriptions (GET, POST, PUT, DELETE)
• Tests
  • Everything should be tested, probably similar to subscriptions.

userId is injected by the frontend proxy into the API calls, just like it's done for subscriptions.

Collection tagging, or adding collaborators or edit links is all not in scope for this issue.