Refactor configuration file loading

[christianparpart]

The current way of loading the config file has been incrementally growing, and thus, also its technical debt. It's time to clean the last(?) dark corner of the source code up.

Main design goals

• [x] enable the user to have a minimal configuration file (all values should be defaulting)
• [ ] easily maintainable config file syntax (stick with yaml for now?, later toml/...?)
• [x] allow generating website-documentation out of the config file's key definitions
• [ ] allow easy upgrading, possible auto-updating config entries, if necessary/possible
• [x] allow auto-constructing a full non-defaulting config file template
• [x] integrate auto-generated website into ghpages CI hook

Config file syntax

At first I think it should remain YAML, but i'm not hard-lining here. Later on the following come into my mind, iff it turns out to be an all-inclusive upgrade:

• YAML: stick with it, known already, but some might not like forced indentation
• TOML: looks like a mix of yaml and ini, so not too alienating, but easy to understand
• LUA: do we really want to go for a more dynamic config language to be more powerful?

[Yaraslaut]

Info about missing entries implemented in https://github.com/contour-terminal/contour/pull/1585 At the moment, we do not upgrade user config file to preserve comments and if implemented in simplest way upgrade will cause user profiles to specify all values while we allow to set specific values in the profile. Implementation of complete upgrade will require some time and can be done in the future

[Yaraslaut]

At the moment config loading let easily add config entries and we can generate default config and missing entries from executable, extending to other formats will lead to copy of read/write logic and can be postpones until reflection will appear in c++ (hopefully 26)