Make the software compatible with the OpenSprinkler OSBo board

This is a first version of a change that isolates the sprinkler application software from the specifics of the hardware interface, i.e. define a hardware abstraction layer (HAL). The goal is for the application to support both the Sprinkler beagle-16 board and the OpenSpinkler OSBo board. The limitation is that we need to support only one board at a time.

The HAL interface is defined in term of resources that a typical sprinkler system will use: N zones, each controlling a triac or relay through one output pin, one rain input pin and one button input pin. How the zone pins, rain pin and button pin are accessed, and their active/inactive levels, is HAL's business.

This code contains 3 HAL variants: one to drive the Beagle-16 board (hardware-beagle16.js), one to drive the OSBo board (hardware-osbo.js) and a null HAL for testing (it provides application-level traces of the software activity).

The sprinkler application loads a module named "hardware.js": the recommended installation method is to create "hardware.js" as a symbolic name to the proper implementation.

Since the OSBo board uses an indirect access to the zone pin through a shift register (i.e. sequential access), the HAL interface provides a setZone() function to set each zone value, and then a apply() function to let the HAL module performs the actual update.  The HAL module for the OSBo board only convert and store the zone value in setZone() and the real output is performed in apply(). It supports any number of extension boards, driven by the number of zones defined. Because the sprinkler software tends to set all zones off in bulk repetitively, the HAL implementation detects and flags all zone changes since the previous call to apply(): the apply() function does nothing if no change has occurred since the previous call.

Since the Beagle-16 board is direct access, everything in that implementation is done in setZone(), and apply() is empty.

In addition, the HAL variants support the production=true|false options of the sprinkler software, but in a way that is different from before. Instead of not performing the pin access, the HAL module actually loads a 'debug' simulation of a subset of the bonescript library (iodebug.js), enough to cover the primitives used by the sprinkler software. This simulation traces each pin access (actually, it only traces the mode changes and output: tracing the input accesses would be too verbose and not as informative, since the data is not controlled by the application).

The changes to the application code (server.js) is actually pretty minimal, considering the scope of the change.

By choice, the format of the configuration data is designed to coexist side-by-side, as two substructures. This is to avoid hardware havoc when switching from one board to another, and forgetting to change the addresses of pins.