[Proposal] Metadata-driven Wattpilot Core Library using wattpilot.yaml

[ahochsteger]

Currently the wattpilot core library parses a hard-coded set of properties (aka API keys) and provides them as API to read or write the values.
The Wattpilot Shell uses wattpilot.yaml to provide metadata about known properties and messages and uses that information to support all known properties in a generic way so changes can be easily supported and it allows much more (e.g. generation of API docs, command completion, help messages, ...).

I'll propose to move the metadata-driven approach using wattpilot.yaml from the Wattpilot Shell into the core library, so consumers of the library access get the same level of functionality.

Aspects to consider:

• Provide access to properties using both the short API key names as well as the (easier to read) aliases contained in the metadata (e.g. cco and carConsumption)
• Refactor the wattpilot shell into separate classes and files to be easier to maintain and reuse parts of it (e.g. Cfg, WattpilotMqtt, WattpilotHomeAssistant, ... - see PR Full refactoring of shell config handling w/o globals #15 for a start)
• ...

Questions:

• How to deal with the naming differences (go-eCharger uses "API Keys" - we use "properties")?
  • IMHO the wording "API key" can easiliy confused with API token keys which are part of the cloud API. Maybe it's ok to keep using "properties" and put the wording "API keys" on important places in the docs to make that clear.
• Which Python version(s) are we going to support for the core library. It's not directly connected to this issue, but a major refactoring like this should take that into account. See Python 3.10 requirement #18 for input about that.
• ...