move mapping declaration into util.py with local import into the the module-level function device_classes
add client.get_device_class
adapt example.py with AC monitoring
This fixes#83 - I have the same LP1419IVSM Air Conditioner model, and it causes an error when turning on using wideq.
I've updated the ACDevice class with two new @properties, which are the list of Operations the device supports, and the best-supported ON operation from that list.
This makes the presumption that if the model reports ALL_ON as available, that it is appropriate to use (as the existing code did), but if ALL_ON is not supported by the particular model, it will fall back to using whichever ON Operation it reports as supporting. In the case of the LP1419, that will be RIGHT_ON.
Additionally, as a backstop, this will raise an error if ALL_ON is not supported but there are still more than one supported ON operation - from reading issues I haven't been able to find any evidence that such a device exists, but if one should pop up it'll likely need handling in some creative way.
These new values are now also reported in the ac-config subcommand of example.py.
Finally, this updates the set_on method to use the resultant operation name. This now means that example.py set [id] on works for my air conditioner again, and just in time for the warmer weather!
Instead of using print, let's use Python's logging framework. That
allows switching verbosity easily and filtering out unwanted messages.
Some of the setup code is inspired by what Home Assistant does.
Many people seem to stumble over this (I did, specifying en_US instead
of en-US for example). I don't know of any valid inputs other than two
letter combinations, but three letters could be valid.
