Flexibility refactor ?

[Samuel Bishop]

Describe the feat you'd like
There are a few minor improvements that could be made to the Django backend with a relatively strait forward refactoring of the current code.

• Separating the Alcali models from the models that reflect the salt returner would make it more flexible so that with additional returners could be supported with new code without breaking the existing setup, this way the pgjsonb and sqlite3_returner could be relatively easily supported.
• Adding support for sqlite_returner would eliminate the need to setup a database server since Django could also use the sqlite database backend.
• Separating it out opens up the opportunity for Alcali to safely perform a once off DB setup during install, for the selected salt returner using the Django migrations. This feels like it could simplify the process of setting things up by not needing to manually connect to the database server and create tables as Salt lacks a "create table" module, so while it can setup the database, it currently requires a slightly awkward manual step which would be nice to remove.
• Alcali could also support any future schema changes in the salt returner tables via the same mechanism that selects wether to use the postgres, mysql and pgjsonb models, just by adding an new extra version of the models with a suitable name.

Is your feature request related to a problem? Please describe.
I'd like to support the pgjsonb returner (ticket for that opened #463)

Additional context
I'm happy to do this in my own fork and get it working before opening a PR, I just didn't want to code all this up if it's not a welcome change.