Regression since ba0a4e864a

A lot of services are yet to be updated to start connecting to
`devture_postgres_container_network` as an additional network.
Many are already done, but I'll go through all the others later.

Putting each client into its own network was good for isolation,
but it's quite wasteful in terms of the container network pool.

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.

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