Additional packet types, new events, new commands, address range checking and more

This is the big rework to support my node-RED rfxcom nodes.
I now handle all lighting packet types except lighting4, and all the weather sensor packet types. I have added extra commands where needed to support the new lighting types, all of which now range-check their 'address' parameters. The address parameters (i.e. the deviceId) may now optionally be passed as an array of pre-split strings. I did this because some types use a single character house code, and some a '/' delimited path, and I needed consistency across all lighting types - the original splitting behaviour is not affected.
I have added a commandNumber property to the lighting event parameters, to better support internationalisation of the command names, but the originals are still present.
I have standardised the evt.subtype properties to be strings (they were a mix of string or number depending on the event type). I changed the packet subtype name arrays to BiMaps, so it is easy to convert from subtype number to string or vice-versa (I consider these strings to be essentially arbitrary identifiers so internationalisation doesn't really apply)
I have added many additional test cases to cover these changes
**Comments**
I am finding it inconvenient as well as unnecessary to have one event type for each 'weather sensor' subtype, e.g. th1, th2, ... In my code they are all being handled by a common function, as I have been careful about naming properties in the evt object. If you really need to know the subtype (sometimes the available properties depend on this) rather than just testing using hasOwnProperty(), then this is available as evt.subtype.
I still occasionally see parsing errors, generally giving an 'unknown packet type' message, but once or twice it just stops giving any data messages. I can't reliably reproduce it though :-(
There are a couple of other very minor points - check the TODO's