WIP add custom migration class and prototype example

[AlexCLeduc]

See #122

Seems to work as a concept, not sure we want to go this way until fixtures are "stable", and even then they may change. Long-term to avoid stale migration dependencies, we'll probably want to squash them somehow

• ensure loaddata works within migration RunPython operations
  • initial demo
  • also works when models change and populating a clean DB?
• write migration subclasses that only run in dev/prod/test
• enforce that these custom migrations don't contain schema operation, and only contain RunPython operations.
  • Even better, subclass RunPython and have it not pass the schema_editor argument
• Consider creating a custom management command to generate one of these blank migrations with the right imports?
• Have a concrete plan for fixture files that get updated after already having applied migrations
  • We may want a special migration or runpython subclass for fixture files?
  • can we use fixture files checksums to automatically invalidate a fixture migration and turn it into a no-op?
• Document this whole thing
  • All the possible use-cases (Adding columns, deleting columns, adding prod-only scripts, etc.)
  • what to do with fixture files, scripts that consume excel/csv seed files