Docs: fix warnings and enforce no warnings

Context

Based on !3950 (merged) that fixes some warnings.

Fixes all the warnings in the documentation, and furthermore, changes the build so that warning == error. This will make the build:documentation job fail in MRs that introduce documentation warnings. Happy documenting!

Orphans

In order to fix some errors about pages missing in the toctree, I had to declare :orphans: (see here). These are pages that we do not need to add in the toc tree:

• docs/CHANGES.rst: WARNING: document isn't included in any toctree
• docs/protocols/checklist.rst: WARNING: document isn't included in any toctree
• docs/protocols/tenderbake.rst: WARNING: document isn't included in any toctree

I'm fairly sure that these pages are not meant to be in the toctree, and are referred to through other means.

• docs/alpha/plugins.rst: WARNING: document isn't included in any toctree
• docs/developer/javascript.rst: WARNING: document isn't included in any toctree

For these two, I'm not so sure. For now, I've declared them :orphan: but I can update if needed.

cli-commands

The manual page for binaries includes raw html files that are not present in the publish:documentation job. This throws a bunch of warnings. I had to surpress these warnings, as they do not signify any error and would otherwise make the job fail. However, I couldn't find a better way of doing so than removing the includes with a sed in the cli-commands.rst files.

venv

I noticed that the publish_documentation jobs were re-installing the python dependencies, even though they should be available in the image. this is solved by running $HOME/.venv/bin/activate at appropriate places.

Manually testing the MR

Compare the log of the build:documentation job of this MR with some other. You can also trigger the publish:documentation_full job in the manual stage and see how that looks.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, the Development Version section of CHANGES.md for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR