This is an attempt at optimizing service startup.

The effect is most pronounced when many services are restarted one by one.
The systemd service manager role sometimes does this - for example when `just install-service synapse` runs.
In such cases, a 5-second delay for each Synapse worker service
(or other bridge/bot service that waits on the homeserver) quickly adds up to a lot.

When services are all stopped fully and then started, the effect is not so pronounced, because
`matrix-synapse.service` starts first and pulls all worker services (defined as `Wants=` for it).
Later on, when the systemd service manager role "starts" these worker services, they're started already.
Even if they had a 5-second wait each, it would have happened in parallel.

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

Related to https://github.com/mautrix/signal/issues/422

`--mount` is safer, as `-v` has the side-effect of creating the "source"
destination as a directory if it doesn't exist yet.
We don't need such magic.

Related to e5130372b9.

Depending on the `options` that people provide, this may break
compatibility.

Depending on the `options` that people provide, this may break
compatibility.

This is what we do for Synapse as well.

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

Looks like the migration to the Go-based Signal bridge hardcoded the
`signalbot` username instead of using the variable we had.
Related to: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3041

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

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

Such a core service probably belongs better when it's in the homeserver network

This is mostly so as to avoid referring to variables from other roles,
like `matrix_nginx_proxy_proxy_matrix_client_api_addr_with_container`.

This should come (and already does) from group_vars/matrix_servers