Introduce ProfileDefaults class and use it in ProfileGenerator

Second part of my project to carve out pieces from @tcanabrava's unmerged KConfigXT port (MR !71 (closed)) into parts that are easier to review and merge. I tweaked this one quite a bit:

• changed a bunch of default value accessor names (i.e. future KConfigXT entry names) for what I hope is better naming,
  • (if you're interested in more naming shenanigans, look at the .kcfg files in my WIP KConfigXT migration branch while it exists)
• fixed some values which weren't accurate anymore, according to current master,
• threw out the icon name default, which @nicolasfella removed in a commit this year,
• changed functions such that isMobile and canSuspendToRam is explicitly passed in, and used the exact set of parameters needed rather than the full profileGroup, isMobile, canSuspendToRam, canSuspendToDisk party,
  • (KConfigXT can deal with this too, via parameters)
• refactored `ProfileGenerator::generateProfiles() which the original MR mostly scrapped, but to get it merged sooner, we're keeping that logic until the KConfigXT port is actually done.

Note: This will conflict with MR !200 (merged), either one can go in first and the other one will get an easy merge conflict resolution once that happens. The conflict is caused by ProfileGenerator using its own Modes enum, which MR !200 (merged) replaces with the new PowerDevil::Enum::PowerButtonAction.

---

Commit message body

ProfileDefaults is meant to be used by the upcoming KConfigXT port of profile configurations, as a more declarative way to query defaults. But we also want it to stay in sync with ProfileGenerator as long as that class still exists.

By using ProfileDefaults in ProfileGenerator::generateProfiles(), we can both ensure that any change to default values will be picked up by the future KConfigXT code, while also simplifying the generateProfiles() function itself.

This commit does not introduce functional changes to profile generation, care has been taken to ensure that no default values were changed while being factored out into ProfileDefaults.

The naming of the new default value getters partially matches that of the existing config groups and keys, but deviates in some places with an eye on future (hopefully better) KConfigXT naming.