Provide NodeJS Buffer like APIs to Decoder and Encoder

[FokkeZB]

The Decoder currently gets an Array, not a Buffer because the otto JS vm we use does not know the NodeJS Buffer API (see #299).

The NodeJS Buffer API has some really nice read/write* methods to read and write numbers of different formats from/to an offset in the buffer. This would remove the need for manual bit shifting, which puzzles many (new) users.

Before:

var myInt32 = (bytes[0] << 24) + (bytes[1] << 16) + (bytes[2] << 8) + (bytes[3]);
var myInt16 = (bytes[4] << 8) + (bytes[5]); 
// var myFloat =  IMPOSSIBLE?

After:

var myInt32 = bytes.readInt32BE(0);
var myInt16 = bytes.readInt16BE(4);
var myFloat = bytes.readFloatBE(6);

What we should look into is loading a browser JS implementation of Buffer:

https://github.com/feross/buffer

It is quite big, but provides a lot of convenience to users. We could also wright a lighter wrapper around the underlying ieee754 with just the read/write methods.

Ideally we'd pass Buffer.from(bytes) to the Decoder so the user can work with it right away.

In the Encoder we could pass an empty buffer as 3rd argument which the user can fill (no need to return) using the write methods.

[johanstokking]

I prefer a lightweight implementation on top of ieee754 for reading and writing signed/unsigned 8/16/32 bit integers little/big endian, booleans, and bit sets and reads.

[FokkeZB]

Me too, and we should then have the same API on the Arduino. Provides a nice level in between protobufs and bytes.

[johanstokking]

Yes. I would, however, not change the Encoder as it is for portability. Let it return a byte array, so simply return buffer.toArray();. People are not entirely stupid and it avoids a lot of magic in the Handler to add a custom parameter and check for return type.

[htdvisser]

@AntoineRondelet, @romeovs?

[johanstokking]

We can use Google Protocol Buffers or Cayenne Low Power Payload