Selfbuild appservice-irc bridge

The git module will create it anyway, but that would likely use `root:root`.

I got at least a few reports of people pasting these statements one by
one and missing the `;`.

We log everything in systemd/journald for every service already,
so there's no need for double-logging, bridges rotating log files
manually and other such nonsense.

Well, they still do go to that DB by default,
but our docs give a better command to users, which would do the right
thing.

This fixes things to make them compatible
with the changes done in 95346f3117

Fix typos

In short, this makes Synapse a 2nd class citizen,
preparing for a future where it's just one-of-many homeserver software
options.

We also no longer have a default Postgres superuser password,
which improves security.

The changelog explains more as to why this was done
and how to proceed from here.

Prompted by this: https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/779#issuecomment-764807507

Update element-web (1.7.16 -> 1.7.17)

I had intentionally held it back in 39ea3496a4
until:
- it received more testing (there were a few bugs during the
migration, but now it seems OK)
- this migration guide was written

When validating LE certs, do not wait for a random time

While administering we will occasionally invoke this script interactively with the "non-interactive" switch still there, yet still sit at the desk waiting for 300 seconds for this timer to run out.

The systemd-timer already uses a 3h randomized delay for automatic renewals, which serves this purpose well.

The `mobile` branch got merged to `master`, which ends up becoming
`:latest`. It's a "rewrite" of the bridge's backend and only
supports a Postgres database.

We'd like to go back (well, forward) to `:latest`, but that will take
a little longer, because:
- we need to handle and document things for people still on SQLite
(especially those with external Postgres, who are likely on SQLite for
bridges)
- I'd rather test the new builds (and migration) a bit before
releasing it to others and possibly breaking their bridge

Brave ones who are already using the bridge with Postgres
can jump on `:latest` and report their experience.

Related to 69f71f48

Discussed in https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/791

> WARNING: Error loading config file: .dockercfg: $HOME is not defined

.. which appeared in Docker 20.10.

Building `master` or something like this was failing.

Newer versions (`master`) use things like `--platform=...`,
which are not supported unless we enable the new BuildKit building
backend.

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

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/737

I feel like timers are somewhat more complicated and dirty (compared to
cronjobs), but they come with these benefits:

- log output goes to journald
- on newer systemd distros, you can see when the timer fired, when it
will fire, etc.
- we don't need to rely on cron (reducing our dependencies to just
systemd + Docker)

Cronjobs work well, but it's one more dependency that needs to be
installed. We were even asking people to install it manually
(in `docs/prerequisites.md`), which could have gone unnoticed.

Once in a while someone says "my SSL certificates didn't renew"
and it's likely because they forgot to install a cron daemon.

Switching to systemd timers means that installation is simpler
and more unified.

We'll be adding `.timer` units later on, so it's good to be
more explicit.

This reverts commit 2a25b63bb6.

Looking at other roles, we trigger building regardless of this.
It's better to always trigger it, because it's less fragile.
If the build fails and we only trigger it on "git changes"
then we won't trigger it for a while. That's not good.

Triggering it each and every time may seem like a waste,
but it supposedly runs quickly due to Docker caching.