This allows us to eliminate the companion and decrease overhead for
simple servers which do not use workers.

This saves up 1 container network and avoids going through extra proxies
unnecessarily.

Downsides: decreasing security slightly due to less networking isolation

Benefits:

- decreased complexity
- having a generically-named `matrix-addons` network we may use for other things now (client apps, etc.)
- not exhausting the container networks pool with 2 (or more) networks and using just 1

This also updates validation tasks and documentation, pointing to
variables in the matrix-synapse role which don't currently exist yet
(e.g. `matrix_synapse_container_labels_client_synapse_admin_api_enabled`).

These variables will be added soon, as Traefik labels are added to the
`matrix-synapse` role. At that point, the `matrix-synapse-reverse-proxy-companion` role
will be updated to also use them.

matrix-nginx-proxy is going away and this is one of the features it
offered.

This feature will have no equivalent in our new Traefik-only
setup, although it's possible to implement it manually by using
`matrix_client_element_container_labels_additional_labels`

This is completely untested.

This is still very far from usable.

Various bridges and bots are still talking to
`matrix-nginx-proxy` instead of the new `matrix-homeserver-proxy` role.
These services need to be reworked. While reworking them,
various cleanups are being done as well as adding Traefik-labels to
those that need them.

.. because matrix_mautrix_signal_version is used in other places
which do not expect it. For example: `matrix_mautrix_signal_container_image_self_build_branch`

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

`matrix_media_repo_identifier` is already defined in the role defaults,
which is a better role to have it anyway.