Very timid beginning framework for BLE communication

[Linus Torvalds]

Dirk, Anton, (and possibly others who currently use RFCOMM),

would you mind taking a look at my "ble-prep" branch in

      https://github.com/torvalds/subsurface-for-dirk.git ble-prep

that I have *not* made into a pull request yet, because I don't
actually have anything to test with.

It's really just three commits:

      custom serial: pass device_data_t to bluetooth operation function
      Expand 'bluetooth_mode' from a boolean to an emun
      Prepare to split the custom serial operations up by RFCOMM-vs-BLE

and each of them actually tries to be a total no-op at this time. But
the intent is to make it possible for core/qtserialbluetooth.cpp to
simply have a different set of operations for BLE devices where RFCOMM
doesn't work.

My plan (which may or may not work) would actually be to turn the
Suunto EON Steel into a user of the serial emulation code too, for the
BLE case there - even though the native model for the EON Steel isn't
really "serial" at all, but a packet format with command/reply on top
of USB HID (and now on top of BLE GATT with the new firmware). But I
think it should probably be possible to use the same serial
abstraction to then write the BLE packets instead.

But that series of three commits doesn't do any of that. It just tries
to do no-op prep on code that I don't actually know at all, which is
why I'd like somebody else to take a look at it.

In particular, somebody should probably test that it still works with
the RFCOMM model. I'm particularly worried about devices that can do
*both* traditional bluetooth *and* BLE. Because right now it just says
that if the device can do BLE, we'll pick the BLE model. Of course,
right now that BLE model ends up falling back to the same old RFCOMM
code (which would fail on a BLE-only device), so it should still work
with a "RFCOMM *and* BLE" device, but whatever..

Comments?

And yes, if somebody who actually knows that code (I'm looking at you,
Anton) actually knows the Qt bluetooth interfaces and would fill in
the open/close/read/write cases for the GLE GATT case, that would be
great. Because right now I have a device that can do BLE, but going
from "USB HID" to "BLE GATT" is a fairly big step. For example, it's a
packetized protocol, and the packet size has changed.

In contrast, somebody who has a Perdix and already knows it, may have
a much simpler time with the protocol that is already just a serial
stream and isn't really packetized (and the BLE GATT thing is just a
transport for that).

                  Linus