Refactor data structures for table constraints

This is a long overdue continuation of some previous refactoring effort.
Before this we used to store the columns a table constraint belongs to
within the constraint object itself. So for example, a foreign key
constraint object would store the referencing as well as the referenced
column names. While initially simple, this approach has the downside of
duplicating certain data, thus breaking ownership and complicating
matters later on. This becomes obvious when renaming the referencing
column. The column name clearly is a feature of the table but in the
previous approach it also needs to be changed in the foreign key object
as well as in any other constraint for this field even though the
constraint itself has not been touched. This illustrates how a
constraint is not only a property of a table but the field names (a
property of the table) are also a property of the constraint, creating a
circular ownership. This makes the code hard to maintain. It also
invalidates references to constraints in the program needlessly, e.g.
when only changing a column name.

With this commit the column names are removed from the constraint types.
Instead they are now solely a property of the table. This, however,
raised another issue. For unique constraints and primary keys it is
possible to use expressions and/or sorted keys whereas for foreign keys
this is not possible. Additionally check constraints have no columns at
all. So when not storing the used columns inside the constraint objects
we need to have different storage types for each of them. So in a second
step this commit moves the code from a single data structure for storing
all table constraints to three data structures, one for PK and unique,
one for foreign keys, and one for check constraints.

By doing all this, this commit also changes the interface for handling
quite a bit. The new interface tends to use more explicit types which
makes the usage code easier to read.

Please note that this is still far from finished. But future development
on this should be a lot easier now.

DB Browser for SQLite 3.12.2

DB Browser for SQLite 3.12.1

Simpler version for AppImage and branch name in the continuous release

The command `git rev-parse --abbrev-ref HEAD` is not returning the branch name
in the travis server, and for the version in AppImage filename it would be
enough to have the short commit id.

Note that these changes are branch dependant.

See issue sqlitebrowser#1092

Remover unused reference to the master branch

This command is failing

Update Arabic translation (sqlitebrowser#2406)

sqlitebrowser#2405
# Conflicts:
#	src/translations/sqlb_ar_SA.ts

DB Browser for SQLite 3.12.0

Update version number for 3.12.0

Updating version number for 3.12.0-rc1

We're using 3.11.300 for the 3.12.0-rc1, in order to keep
numerically lower than 3.12.0, which will be used for the
actual release.

Only include the build date for nightly builds.

Our alpha and beta releases use patch numbers greater than 99, so
were being caught by the version string check.