Extend branding options for new Docker image

[mxsasha]

Third party usage of our new docker image is mainly aimed at API users for now. However, there are several other deployments (DK, BR, AU) that will likely also want to use this new deployment method.

Note that by default, the Docker image is unbranded per #1156. This isn't adjustable further though.

Possible desired modifications

• The basic branding of the frontend: colors, logo.
• Extensive frontend changes: adjustments to potentially any CSS or templates.
• The content: translations into local languages, and their own news posts. There is already a content mechanism based on markdown/gettext files, but it's clunky.
• Requirements of individual tests, e.g. whether sectxt has a score impact, or whether a particular cipher is good, bad or warning.
• Additional features like requiring a T&C approval.
• Other meta like rel=me links (currently in templates), security.txt (currently in git)

Note that some of these interact: if someone changes the requirements of a test, that will usually require updating the explanation content in all their languages.

Our goals

• Limited maintenance overhead for us: the additional burden of increasingly complex customization should lie more with the third party.
• No softcoding, where giant complex poorly tested config files start defining most of the behavior.
• As smooth as possible upgrade process for third parties: everyone benefits if they remain up to date.
• Minimum impact of support for third party deployments in our ability to make our own decisions about our tests and requirements.

Early ideas

• An improved content framework that makes it easier to load external languages. Third parties only need to provide their translations file. It is inevitable that they may need to add or change content when updating to a new release.
• Adding settings for basic styling of the website, which could work for logo and colors.
• Add template override support through a Docker volume. Flexible, but hard to test, and may break with upgrades. We also currently do not document changes to this level at all. Note that templates contain some important rendering logic too.
• Have third parties fork the repo, and adjust our build process so it can run in a third party repo and build packages into their package repository as well. Full flexibility, but more work to keep updated with new versions. Less likely to break silently, and much easier to test.

Personally, I dislike template override support as it seems like the worst of both worlds: limited flexibility and easy quiet breakage. I'd like to see content handling improved anyways, which would separate it entirely from the other improvements.

[apio-sys]

Thanks for this update that I didn't see before even though it's there since a while. I'm working on the FR version in a forked repo and keep my fork up2date with main as often as possible (sometimes having to resolve some conflicts but that's manageable). I have also posted some further questions in #1341 . Shall we close that discussion and continue this topic here are treat both separately?