Introduce BasicWindowCovering and deprecate WindowCovering

[timcharper]

The pattern for most accessories is to require only the required
characteristics, and then allow the specification of optional characteristics
via the inclusion of interfaces. This pattern was not followed with
WindowCovering. Worse, for reasons currently not understood, the inclusion of
the HoldPositionCharacteristic causes the homekit pairing with the bridge to be
completely unresponsive. (See issue #56)

Change is made in a backwards compatible way, so that existing implementations
that depend on WindowCovering as implemented will continue to function

Addresses #56

[andylintner]

Hmmm. Any idea which one caused it? I'd like to try fixing it instead of removing them - I actually have WindowCovering working in my branch of the OH2 add-on.

[timcharper]

I'm not exactly sure right now; I have the sample hap app with a mock window covering; if I enable it, then everything comes crashing down and I have to remove the mock bridge and pair it again from scratch. It's really bad. Stripping it back to the required characteristics worked.

[timcharper]

Perfectly reasonable to hold the merge here until we have better clarity on what's broken.

[timcharper]

See #56

[timcharper]

@beowulfe The network frames patch from @ccutrer did not fix it. However, I've narrowed it down to being caused by the inclusion of setHoldPosition characteristic; the window covering works fine with the obstruction detected characteristic.

I'm not really sure why it's broken, I've double and triple checked the HoldPositionCharacteristic implementation, the UUID is correct, it's write-only, etc. It's correct per the Homekit spec. However, including this characteristic definitely breaks HAP-Java in really bad ways! :/