Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2427

* Allow the mautrix whatsapp relaybot to be enable with a variable

This allows a user to enable the relaybot by setting a variable in
`vars.yml` in the same way that the mautrix signal relaybot is
configured.

* Correct default values for mautrix whatsapp relaybot variables

* Add documentation for using the relaybot with mautrix whatsapp

* Adjust variable names to better reflect what they do

* Set default variables properly and use to_json in template

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

`ephemeral_events`` and `sync_with_custom_puppets` have been flipped
to keep up with the default upstream config:
b33bd9c4a7

Not doing {% if matrix_admin %} checks in the YAML also fixes some issues
with indentation being incorrect sometimes.

This should be backward compatible, except for mautrix-signal's case
where `matrix_mautrix_signal_bridge_permissions` previously existed
as a string, not a dictionary. `tasks/validate_config.yml` will catch
the problem an even provide a quick fix.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1912

Co-authored-by: ThellraAK <ThellraAK@pop-os.localdomain>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>

Fixes #1873

The same logs still go to the systemd journal.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/806

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

If a service is enabled, a database for it is created in postgres with a uniqque password. The service can then use this database for data storage instead of relying on sqlite.

- following spantaleev transition of the telegram brigde
- adding a validate_config task

The goal is to move each bridge into its own separate role.
This commit starts off the work on this with 2 bridges:
- mautrix-telegram
- mautrix-whatsapp

Each bridge's role (including these 2) is meant to:

- depend only on the matrix-base role

- integrate nicely with the matrix-synapse role (if available)

- integrate nicely with the matrix-nginx-proxy role (if available and if
required). mautrix-telegram bridge benefits from integrating with
it.

- not break if matrix-synapse or matrix-nginx-proxy are not used at all

This has been provoked by #174 (Github Issue).

Use Jinja2 lstrip_blocks option in templates to ensure consistent
indentation in generated files.

As suggested in #63 (Github issue), splitting the
playbook's logic into multiple roles will be beneficial for
maintainability.

This patch realizes this split. Still, some components
affect others, so the roles are not really independent of one
another. For example:
- disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse
and riot-web to reconfigure themselves with other (public)
Identity servers.

- enabling matrix-corporal (`matrix_corporal_enabled: true`) affects
how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to
put matrix-corporal's gateway server in front of Synapse

We may be able to move away from such dependencies in the future,
at the expense of a more complicated manual configuration, but
it's probably not worth sacrificing the convenience we have now.

As part of this work, the way we do "start components" has been
redone now to use a loop, as suggested in #65 (Github issue).
This should make restarting faster and more reliable.