Add Paver task for auto-generating protobuf def...

Add Paver task for auto-generating Protocol buffer message definitions,
from the signatures of the methods of the `Node` class, in the `Node.h`
header.

Tool-chain
==========

 - Auto-generate Protocol buffer message definitions from `Node` class
   method signatures _(see `Node.h`)_.
 - Auto-generate Protocol buffer API code for Python and for [Arduino
   _(`nanopb`)_][1].
 - Compile Arduino sketch using SCons.
 - Flash compiled sketch _(`.hex`)_ to Arduino.
 - Interface with Arduino using `nadamq.command_proxy` module _(see
   `README.md`)_.

TODO
====

 - Convert union message type encoding to the format used [here][2].
  - The reason is that `nanopb` does not handle the union type encoding
    recommended on the [Protocol Buffers site][3] well, where the type
    of the message is included in message.

Union type message handling - Google's vs. `nanopb`
---------------------------------------------------

It seems that Google's reference Protocol Buffers implementation
efficiently encodes union type messages with a type field, where only
the populated sub-message ends up being encoded.  However, using
`nanopb` with a union type message with a type field results in every
sub-message entry being encoded in the message which is _not_ what we
want.

This seems to be because `nanopb` converts all message types directly to
C structures, where each field corresponds to an allocated member in the
structure.  The effect of this is that structure members for `optional`
fields are still allocated _and_ seem to still be encoded in the
resulting message.  To avoid this behaviour, it is necessary to switch
to using the `nanopb` approach described [here][2].

[1]: http://koti.kapsi.fi/jpa/nanopb/
[2]: https://code.google.com/p/nanopb/source/browse/examples/using_union_messages/README.txt
[3]: https://developers.google.com/protocol-buffers/docs/techniques#union