Binding for MiOS (Vera) Automation controllers

This binding exposes read, and read-command, access to Devices controlled by a MiOS Home Automation controller, such as those seen at http://getvera.com.

It exposes the ability to do the following things in the MiOS HA Controller
* `Devices` - Read State Variables & Device Attributes, and invoke (single parameter) UPnP Commands to control the Device.
* `Scenes` - Read the current execution state of a Scene, and invoke those Scenes within the remote HA Controller
* `System` - Read System-level Attributes.

It uses the _remote control_ interfaces (aka "UI Simple" JSON Calls, and HTTP Long-polling) of the MiOS HA Controller to keep the _bound_ openHAB Items in sync with their counterparts in the MiOS HA Controller.

The "guts" is outlined in the root-level `README.md` file, along with the JavaDoc that's in the code (although, the `README.md` is better).  

The binding uses the openHAB _Transformation Service_ extensively to "map" the Data & Commands between the two systems.  I provide a set of example MAP transform files in the `examples/transform` directory of the Binding, but these can readily be augmented without needing to tweak the code.

Original code was used from the XBMC Binding, and then heavily modified.  Snippets included from the HTTP Binding for the various datatype mapping functions.

Submitting for early feedback, there will probably be a lot since it's my first binding  ;)
The initial binding string form is targeted to support binding to anything that can live in a Vera Unit, without reverting to any specific subset.  As a result, I put forward an initial syntax that can be "dumbed down" at a later point using various synonyms/aliases (etc) and in some cases (like unit:) become more optional.

In the case of the *unit:* prefix, I was deliberate in the choice of using *keyword* : *value* style for each of the elements of the string.  I looked over a number of other bindings, and found the styles used a little inconsistent.  I ended up using one that _consistently_ used a CSV of *keyword* : *value* pairs.

For *unit*, I intend for it to evolve to being an optional component (a "*default*" unit, if you will).  Most people only have 1 Vera unit in their house, so I didn't want to burden them with having to specify that portion of the binding string.  Users who then grew into a larger deployment, would then add the extra part to those specific bindings, along with the instance id in openHAB config.

ie.  Keep it simple for intro-users, but not *require* that simplicity out of the gate (it can always be added)

I also didn't want to hold the binding until that level of simplicity was present in the code.  It's already way-past MVP level, in terms of usage, functionality, performance and stability...  I've been lucky to have a bunch of tenured Vera users giving me feedback for the last few months.


Anyhow, the sub-patterns for device, scene, etc are intentional.  MiOS does *not* maintain unique entity-ids across it's system (oddly, unlike UPnP).   Experience from using the URL ("UI Simple") form of access to Vera shows this to be confusing to end-users (folks get the parameter names incorrect, along with the serviceId, along with a few other pieces)

The id "1" can be found in both Devices as well as Scenes (for example).  It goes back to my original theme of using a fixed # of "well known/understood" *keyword* parts, with any data/values being kept in the *value* part.

Otherwise you'll end up with rather arbitrary parameter/value combinations, where "parameter" continually has to be augmented each time a new Device and/or DeviceType is added to the system.  That was specifically an anti-goal when building the binding.

ie. Build it to bind *anything*.  Let the users express, through external configuration, how that should look and provide examples of how to do exactly that.

Service aliasing, for example, is built in.  Defaulting (for *command:*, *in:*, and *out:*) isn't present yet but is definitely on the road-map (I even had an impl for it, but didn't think it was good enough)...  Defaulting will be implemented after the binding is merged, since it was the most asked for item in the user-feedback I've received... for now, they're mostly cutting/pasting from working examples, and then changing the Device/Scene Id's to match those in their systems.


BTW: Also deliberate to use a URN "Path" style for the service, instead of splitting it to service and variable names.  You'll see that device, system and scene are all very consistent in this respect (as would "room" and "section" be if I could add them).

In some cases, you want to bind to the *attribute* section of a Scene or Device, and not just the *service* section.  I specifically wanted a single representation (and parameter) to handle all of it in order to an explosion of <param> names.  The best example I could find for this was the part component of a URN.

ie. The _device_, _scene_ and _system_ parts are a simple expression of how to _locate_ the data, and the _in_, _out_ and _command_ parts are the expression of how to _transform_ the data.