Draft: Rest api support

[kugel-]

Incomplete because I don't own a lot of devices for testing. I left out light bulbs and blinds for now, but also templates and triggers.

I hope the general architecture is alright. Retrofitting AHA-API was a slight pain but I think I got it. On the downside, the output may be different depending on the API, but I hope it's not too mich of a concern as long as you can force AHA for any given device. I did not attempt to fully unify output and class members because I anticipate that AHA API will be dropped eventually (in a few years). I wouldn't wand to severely cripple REST API support just because of ongoing AHA support.

However, I do try unify things where it's simple and worthwhile to do, especially for things that are used by HA.

The REST api does not expose flat devices anymore. Devices are comprised of one or more units, and units are comprised of one or more interfaces, although typically a device is also a (single) unit with numerous interfaces. I tried to reflect this in the code base to make future maintenance easier and less surprising. At the end of the day, most of the interesting stuff is in the interfaces.

So in a nutshell:
unchanged classes:
FritzhomeDevice* (except FritzhomeDeviceBase)
FritzhomeTrigger
FritzhomeTetmplate

modified classes:
FritzhomeDevice
FritzhomeDeviceBase
FritzhomeEntityBase

new classes
FritzhomeDeviceAHA
FritzhomeDeviceREST
FritzhomeInterface
FritzhomeMixin
FritzhomeUnit
FritzhomeUnitBase

For AHA the class hierarchy is largely unchanged, except it starts with FritzhomeDeviceAHA at the bottom.
For REST the class hierarchy does not include any of the FritzhomeDevice* classes anymore. Instead,
the hierarchy includes FritzhomeUnit and Fritzhome*Interface classes. I created the REST hierarchy first (basically from scratch). When reintegrating AHA support I figured it would be easiest to keep the related code unchanged (AHA API in FRITZ!OS is very unlikely to change and new endpoints are going to be REST-exclusive (see thermostat offset control).

Further complication comes from the two REST namespaces, overview and configuration. On the one hand, "overview" allows to get the big picture of all devicesin a single REST request. But on the other hand, only "configuration" gives full access. In the overview the "interfaces" nodes lack lack several fields (such as temperature offset).

As I said, this is very incomplete and many controls to not work yet. I want to get some general feedback on the general feedback before infesting more time.