This bootstraps the usual commands related to topics management.

Previously the file patterns that sphinx-apidoc must exclude, stored
in the APIDOC_EXCLUDES variables, were expanded by the shell before
executing the tool resulting in a really long list of files to exclude.
Each time a file was processed by sphinx-apidoc, its path was compared
against that long list of files which was significantly slowing down
the apidoc generation process.

So ensure file exclude patterns are quoted to avoid shell expansion
and greatly speedup sphinx-apidoc execution.

Such files are not of interest for API documentation and can generate doc
build errors.

Since swh-web tests reorganization, we now have such file so we need to
exclude it from apidoc processing.

Related to infra/sysadm-environment#4669

Related to infra/sysadm-environment#4647

- pre-commit from 4.1.0 to 4.3.0,
- codespell from 2.2.1 to 2.2.2,
- black from 22.3.0 to 22.10.0 and
- flake8 from 4.0.1 to 5.0.4. Also freeze flake8 dependencies.

Also change flake8's repo config to github (the gitlab mirror
being outdated).

Those are not really useful as links to source codes are already
present and are out of scope for a user documentation.

Related to T3117

Related to T3117

Also ensure apt-transport-https package is installed.

Current debian stable (bullseye) does not package postgresql-autodoc
so remove it from packages list and add alternative install instructions.

yarnpkg debian package does not play well with nodejs installed from
nodesource so add instructions to install its latest version through
its homemade debian package.

- Use the generic `virtual environment` instead of `virtualenv` and
  point to the official Python documentation.
- Use the internal reference to the getting started doc.
- Mention there is tons of good tips in the documentation about
  the Docker environment.
- Update the link to the documentation on how to submit patches.

The `--now` flag to `systemctl disable` will stop (on top of disabling)
the given services. `systemctl disable` also accepts multiple services
as argument.

We can thus replace 4 commands in the developer setup documentation by a
single one.

The tutorial on how to “run your own Software Heritage” felt quite dry.
Meanwhile, more details on how to start using the local
instance were already available in the documentation on how to use
the Docker environment.

So we pull in the relevant sections from
`swh-environment/docker/README.rst` to complement the existing tutorial.

Related to T3117

Related to T3117

Related to T4135

Related to T4373

It can be convenient to run the global swh documentation in the
current venv instead of using tox (notably to save time by skipping
dependencies installation).

It looks like the Makefile in docs folder was not really maintained
regarding that kind of documentation build so fix it in order to
restore local build.

This would warrant a more thorough guide, but I'm not the best person to
write such a guide, and this is better than having nothing.