For example: at the moment a rouge RM could upload a compromised .deb
to our custom APT repo without our process being able to identify it,
so let's not even pretend that we are working towards "rouge RM
resistance" just yet.

Refs: #12629

Fixup against 00430cb5.

Fixup against 00430cb5.

Will-fix: #12629

The previous pattern, `*.{mdwn,html}`, would expand to
`HACKING.mdwn *.html` due to `HACKING.mdwn` existing in the Git root
these days, leading to all .mdwn files in the wiki would be ignored.

We've so far only used it to set Enigmail's configuredVersion
value. We couldn't use /etc/thunderbird/pref/thunderbird.js becaue
configuredVersion must be set via a user_pref to take affect, and that
file cannot set such prefs. However, we can use the extension
override, and completely automate this.

Note: in the thunderbird wrapper we still use 0000tails.js, but in
this instance it is ok, since it's only used for a value that we'll
set each time the wrapper is run.

Will-fix: #12680

We had switched (commit:68eb4074) to 6 months as
we thought we would manually update the basebox ourselves. This doesn't make
sense anymore: we have the basebox updated automatically every time we prepare
a new major release.

This reverts commit:68eb4074 and improves the
phrasing of the re-introduced text.

refs: #12002

Apparently "the next few releases" has sometimes been interpreted as "the next
release". Let's ensure we do this for the next 2 releases at least.

At this point of the release process, mirrors have sync'ed already, so we're
measuring how much space they *already* need.

We're now using a dedicated channel ("test") when testing, and we only use the
alpha one for actually released alphas/betas/RCs. So this line should have been
adjusted (s/alpha/test/) when I introduced the "test" channel.

But since we don't hijack the "alpha" channel anymore, I think the UDFs
on the "test" channel are harmless, and it's probably not worth removing them.

Time will tell if I missed one reason to add these lines in the first place.

Release process: adjust the "Tor blog" section for their new blog engine, and improve it quite a bit.

That's how I've been doing it for ages: no need to block on "Update the website
and Git repository" to start testing.

We already do that a bit earlier.

The *stable* changelog won't give us what we want, and these instructions
must be followed in other cases, e.g. when shipping Linux from backports.

The RM is generally not the best person for such technical writing tasks,
and it feels more consistent to have this done at the same time
as the release notes are written.

This is needed until refs: #12494 is done.