Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 27, 2018, at 2:53 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> 
>> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> 
>>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) QLowEnergyServicePrivate(0xc5271c00)
>> 
>> just realized that 9 / 9 mean the start and end handle for this service.
>> so i guess that also confirms that the service has no characteristics
>> if they are equal.
> 
> That makes sense

More testing shows even less reasonable results.

Android only ever sees the Petrel 2 as type 2 (BLE only) device (even though it should
be a type 3 (dual stack) device).
Trying to force a BLE bonding from nRF Connect makes the BT stack crash.
Trying to download over BLE from Subsurface-mobile on Android fails as described.
But… ignoring the “BLE only” designation and instead downloading via rfcomm succeeds.

Hrmpf.

I guess I’ll have to add a special case for Petrel devices that if they fail on BLE they should
try BT after all, anyway? Not my preferred solution, but I’m not sure what else to try.

/D