We were only checking FKs and Indexes on Tables, but not on Relations. This caused
a bug when PostgreSQL relations were missing Foreign Keys, because
DbInitializerPostgreSql::buildCreateTableStatement() does not include FKs in the
query and relies on DbInitializer::updateIndexesAndConstraints() to create them.
DbInitializer only created the FKs on Tables though, not Relations, so they were
missing there. This can in some situation cause that data in  Relation tables
reference rows from other tables that no longer exist, making the tables
unnecessarily big (it should not happen normally since we handle most of the
deletions manually in order to compensate for missing FK support in SQLite, but
still ...).

By enforcing the check for relational tables too we get the FKs created for
relations on start even on PostgreSQL. This requires that we make sure that
there are no unreferenced data in those tables first, hence the ugly queries in
dbupdate.xml, and hence the DB revision bump.

This problem did not affect MySQL which creates the FKs as part of CREATE TABLE
queries, or SQLite because we don't support FKs there (yet).