Data migrations/Update tasks

This is a bit related to #19 (closed), but might also be useful regardless:

Currently, we do have database migrations, which allow us to upgrade database versions without data loss. However, with some data being stored outside of the database (such as images), there might be potential to have other sorts of migrations or more generic "update tasks" as well - like re-running updated filters, updating stored file formats, ...

The question of course is how to manage that. Some tasks can be (or even have to be) done in the alembic migration (such as moving data out of the database), but some migrations might not concern the database at all.

A few possible solutions:

• Do everything with alembic, even if it doesn't use SQL. This way, we have a single tool responsible for the update migration.
  • We should keep in mind that alembic usually provides "down migrations" and is used to set up the SQL schema in the tests, so weird migrations might cause issues.
• Roll some script that does some basic tasks, depending on the old version and the new version.
  • To automate the process, we would need a way to "stamp" the version into the data.
  • If the script grows, we can do it "alembic" style and put the scripts into separate files.
  • The script could take care of running alembic as well, such that we have a single "update" command (fietsctl update or fietsboek-update)