Binary protocol over bluetooth

[raduiliescu]

Change data exachange over bluetooth to a binary format.

Advantages:

1. data can easily be decoded;
2. more robust to error and is not taking just parts of the packets;
3. can be easily extended:

• for example I want to add next getMs and a packet id to the packets; the bluetooth chip is buffering packets if here is no connection and packets can be get with read.

[StephenBlackWasAlreadyTaken]

First off, this PR is super cool, my biggest issue is that I dont want an app update to make someones currently functional wixel stop being able to communicate with xDrip, can we split this setSerialDataToTransmitterRawData and have it go down two logical paths, one if its the old style, one if its the new style,
Also I would love it if the start of each of these new packets was a version number (this being version 1, that way if we down the road add in some more params we can easily check which version of the a transmitter data parser to use)

[raduiliescu]

Have added a fallback mechanism see line 397

[saercnap]

Consider using something like protocol buffers [1] or thrift [2] instead of manually versioning the binary protocol

[1] https://developers.google.com/protocol-buffers/docs/overview
[2] https://thrift.apache.org/

[raduiliescu]

In general I have some issues with keeping backwords compatibility. Can be a big pain on new development.
In my opinion, xDrip is in a begining phase, so I wouldn't care too much for backword compatibility.
It still involves a lot of DIY and everyone needs to compile the code and install it. Who upgrades the xDrip app doesn't have an issue in upgrading the wixel one.

On versioning I see two possibilities:

1. start with the assertion that xDrip app will support and be backwords compatible with all wixel versions.
   Putting code for this will complicate the things and in this case I'll jump on protobuf. The library might be a bit too big for wixel.
   I've never used it in Java and one issue I see is getting the buffer from notify and feeding the google proto deserializer. Need to know how much to read, because on a write to uart bluetooth can split the packets.
   It will increase a bit the wixel code and will present a problem on where to put/compile the .proto file. Maybe in a different branch and add the protobuf library and compiled C/JAVA output code in wixel-xDrip/ xDrip.
2. keep it simple - put the version in the packet and use it just for checks.
   If the version is what we expected then take the packet, otherwise drop it and signal the users that the wixel software is incompatible.

Please let me know of your thoughts.

[StephenBlackWasAlreadyTaken]

on versioning:
Considdering the only version people are using right now would automaticly stop working if they updated to this, I say we 100% have to support both for at least some amount of time. there are a few hundred people using it right now who may update their app but be SOL because they dont have a miniusb cable to update their wixel.

adding a library to the wixel will be tough, its very tight on space and bceause its so timing dependant I would like to keep from having to jam anything that happens in the main loop from having to touch xdata

[raduiliescu]

Ok. Will implement it to allways be backwords compatible.

[StephenBlackWasAlreadyTaken]

moved StephenBlackWasAlreadyTaken/xDrip-Experimental#12 for rebasing