In cases where pgloader is not enough and we need to do some additional
migration work after it, we can now use
`additional_psql_statements_list` and
`additional_psql_statements_db_name`.

This is to be used when migrating `matrix-registration`'s data at the
very least.

This switches us to a container image maintained by the
matrix-registration developer.

0.7.2 also supports a `base_url` configuration option we can use to
make it easier to reverse-proxy at a different base URL.

We still keep some workarounds, because of this issue:
https://github.com/ZerataX/matrix-registration/issues/47

Missing ` in traefik domains instructions

We were running into conflicts, because having initialized
the roles (users) and databases, trying to import leads to
errors (role XXX already exists, etc.).

We were previously ignoring the Synapse database (`homeserver`)
when upgrading/importing, because that one gets created by default
whenever the container starts.

For our additional databases, it's a similar situation now.
It's not created by default as soon as Postgres starts with an empty
database, but rather we create it as part of running the playbook.

So we either need to skip those role/database creation statements
while upgrading/importing, or to avoid creating the additional database
and rely on the import for that. I've gone for the former, because
it's already similar to what we were doing and it's simpler
(it lets `setup_postgres.yml` be the same in all scenarios).

We were referencing them from `group_vars/matrix_servers` since
recently, but there were no such variables and they weren't being put to
use.

Auto-migration and everything seems to work. It's just that
matrix-registration cannot load the Python modules required
for talking to a Postgres database.

Tracked here: https://github.com/ZerataX/matrix-registration/issues/44

Until this gets fixed, we'll continue default to 'sqlite'.

This has been tested and appears to work.

Looks like there are some that I missed in 087dbe4ddc

I was thinking that it makes sense to be more specific,
and using `_postgres_` also separated these variables
from the `_database_` variables that ended up in bridge configuration.

However, @jdreichmann makes a good point
(https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/740#discussion_r542281102)
that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.

I don't use this bridge, so this is completely untested.

Regression since 2d99ade72f and 9bf8ce878e94, respectively.

When SQLite is to be used, these bridges expect an `sqlite://`
connection string, and not a plain file name (path), like Appservice
Discord and mautrix-whatsapp do.

I don't use this bridge, so this is completely untested.

The only one that remains is `matrix_synapse_database_password`, but
that's something old and should be dealt with separately in the future
(unless it remains as it is).

Related to 9bf8ce878e.

Should have been done during 2a99e84b5bfd9f39, but I've missed it.

Because of this, 9bf8ce878e was also incomplete and would have caused
an error.

I don't use this bridge, so this is completely untested.

Instead of passing the connection string, we can now pass a name of a
variable, which contains a connection string.

Both are supported for having extra flexibility.

`matrix_SERVICE_database_engine` remains as it is - the only one with a
`_database_` infix. Postgres-related ones move to `_postgres_`.

This can be used by various bridges, etc., to import an SQLite
(or some other supported) database into Postgres.