Use an explicit m2m through model between Template and Site

[blag]

Create an explicit through model between Template and Site objects, instead of relying on the implicit model Django creates for us.

There are a lot of guides for doing this that suggest creating the explicit through model, then using RunPython in the migration to copy the data from the implicit through table to the explicit table, and removing the old through table. That is problematic for existing users with large amounts of data. So I ensured that this migration doesn't actually modify the database schema at all - it only modifies the migration state as tracked by the Django migration framework.

I then attempted to add a unique together constraint between Template.name and Site. Django's system check system identified an issue with this:

DJANGO_SETTINGS_MODULE=dbtemplates.test_settings django-admin test
Found 10 test(s).
Creating test database for alias 'default'...
Destroying test database for alias 'default'...
SystemCheckError: System check identified some issues:

ERRORS:
dbtemplates.TemplateSite: (models.E012) 'constraints' refers to the nonexistent field 'template__name'.

WARNINGS:
?: (admin.W411) 'django.template.context_processors.request' must be enabled in DjangoTemplates (TEMPLATES) in order to use the admin navigation sidebar.

System check identified 2 issues (0 silenced).

After quote a bit of searching around, I have been unable to find anything to suggest that PostgreSQL in particular (because that's what I'm using) supports explicit table joins in unique together constraints. It seems like databases, including PostgreSQL, only allow unique together constraints on columns that exist in the same table. Every source I found indicated that it could be done in one of two ways:

1. With composite primary key definitions on the template table and foreign key constraints on the join table
2. A database trigger

Option 1 is problematic because while composite primary keys are technically supported by Django, support for them is limited. And changing the template table to use composite primary keys would be a breaking change for ALL existing users of this app. Frankly, I found this solution to be overcomplicated to begin with, and not very well supported by Django.

Option 2 is perfectly reasonable, but Django itself does not define or track triggers in its ORM, so we would need to do this via migrations by writing SQL ourselves. I don't think trigger definitions are very portable between different DBMSes, and in either case, I thought this was even more overcomplicated than option 1 on top of being difficult to troubleshoot , test, and maintain.

But if it somehow is possible to support unique together constraints/indexes that references a joined table field that is not a simple foreign key to the joined table, this is at least a good start in that direction.

Closes #119, #147, and #152.

@mpasternak You seem convinced that this is possible, do you mind picking this up and getting it to work? Maybe I'm missing something.

[blag]

Two more potential solutions:

3. Construct a materialized view that joins Site with Template.name and add a unique together constraint on that.
4. Only for Oracle DB: add a virtual column or function-based index that derives a value from a joined table, and then add a unique together constraint on that.

Option 3 still relies on database triggers to keep the materialized view up to date, and Django also doesn't support defining or tracking database views in its ORM. Additionally, while MySQL supports views in the most half-hearted way possible (they are essentially saved queries), it does not support adding any sort of unique constraints to views at all. So this solution has zero support from Django's ORM, requires triggers to implement, and still isn't portable across different DBMSes.

Option 4 is also not supported by Django's ORM and is obviously not portable across different DBMSes.