Support for multi-master database setups#313

Hi all! For a project we have tried to integrate this package for versioning our database data. During development things were fine, but it turns out that in production we run into a variety of issues. We narrowed this down to the fact that we are using a multi-master MariaDB Galera database, which has a lot of impact on this package in particular. SQLAlchemy-Continuum uses a `Transaction` table to record all transactions and refers to this table in the `_version` tables. At first I thought that the `id` of the `Transaction` uses the AUTO_INCREMENT value, but instead it uses the `transaction_id_seq` Sequence which should generate sequential ID values as primary key. By default a MariaDB sequence uses an increment of 1, which breaks on a multi-master Galera cluster -- we got a lot of duplicate primary keys when serving multiple requests at the same time. It is also possible to set this increment value to 0, in which case it will interleave the generated values, just like it does for AUTO_INCREMENT values. I might be wrong on this, but some testing on a simple 2-node Galera cluster showed me that these generated values are unique, but are not sequential: we no longer have the guarantee that the highest value is the latest generated value. This in turns breaks the next/previous version queries in Continuum, essentially rendering the plugin useless for our purposes. Theoretically it would be possible to use exclusive locks in our application code to not work on the same database row simultaneously, but that opens up a whole other can of worms called deadlocks. As such we would like to avoid this approach as much as possible. Would it be possible to start adding support for this, or is there something else we are overlooking that would resolve the issues?