Use sites framework to manage multiple domains

We currently run multiple instances of Textcavator for different projects. For larger research projects with multiple corpora, it can be interesting to have a "dedicated environment" for presentation purposes. For maintenance, it would be easier if these can be handled from the same server. Our System Team is also on board with this.

Django's [sites framework](https://docs.djangoproject.com/en/5.2/ref/contrib/sites/) is designed for use cases exactly like ours. (We actually have this enabled already, but the code assumes you have only one site.) We can use this to manage multiple domains from a single server.

Some changes are required in the application. Currently, Textcavator is built with the assumption that a server is only deployed to a single domain. While you can deploy to multiple hosts, the application isn't designed for it.

First, some technical issues occur when you try this:
- SAML configuration: some values should be domain-specific. Because the configuration is defined as a constant, SAML login can only work on one domain at a time, and will be broken on all others.
- User emails (for email verification / downloads) always link to the same domain, rather than the domain that the user visited.
- In our production environment, the config file only provides a single string with the domain, so configuring multiple domains is an issue. I asked Ty about this and this would be a simple fix.
- The `frontend_url` template variable in corpus documentation should be replaced with the site url.

If you fix all this, you get a working application on multiple domains, but each domain would show an identical app. Some settings and data need to be domain-specific. For example:

- Some backend settings are constants, but should be site-dependent, such as the site name, whether SAML is enabled, etc.
- User accounts should be for a single site. (This is how it works right now, with multiple servers. Shared accounts are technically possible, but don't fit our use case.)
- There is a "basic" group for corpus access - new users and anonymous users are automatically part of the group. This must be arranged per site.
- The frontend uses an `environment` file to manage different configurations, but these values should depend on the site. Not sure what is the best way to implement this, but it's definitely solvable.