Identifier fields should always be case sensitive

[ormsbee]

Identifier fields (strings that are local to some context, like usage keys) should be case-sensitive. Right now, it will or won't be depending on the default collation and the database in question. This will lead to conflicting behavior between SQLite (case-sensitive) and MySQL (case-insensitive). Using the db_collation attribute is tempting, but these values are not standardized across databases, which would complicate things when using SQLite vs. MySQL even in day to day dev and testing (never mind the possibility of Postgres).

Investigate what it would take to make a field type that know how to run migrations to set the collation of a field based on the database and database collation settings (so utf8mb4 would map to utf8mb4_bin, but utf8 maps to utf8_bin).

[ormsbee]

Actually, it might be better for the collation to be case-and-accent-sensitive text collation rather than straight binary, since we might want to group upper and lower case letters next to each other in listings where the identifiers are semi-human-readable.

[ormsbee]

This was addressed by creating the collation-aware MultiCollationCharField and MultiCollationTextField along with their underlying collations,py module.