Add qml-module-qtbluetooth support

What does 'add apparmor policy' entail? What does qml-module-qtbluetooth use on the backend? Will it support trust-store prompting (and therefore be a 'common', safe policy group) or will it be an unsafe, 'reserved' policy group (eg, like 'contacts' is today)?

Some info:

The backend for the module is shipped with QtConnectivity, hence doesn't have any trust prompts around. That backend will talk to BlueZ over D-Bus on the system bus for the most part. Additionally, OBEX & RFCOMM (the two most interesting profiles for a start) read from/write to unix file descriptors to exchange data with the remote device. Those files are created by bluez and the descriptors handed over to the app in order to read from/write to it. Reading through the code, file transfers also seem to require temporary files on its own.

http://code.qt.io/cgit/qt/qtconnectivity.git/tree/src/bluetooth/qbluetoothtransferreply_bluez.cpp

What subset exactly is to be opened on the system D-Bus, I don't know exactly atm. However, I do have a Content-Hub plugin and a proof of concept service for sharing files (both, sending and receiving) around in here:

https://code.launchpad.net/~mzanetti/+junk/ubtd (They were created back in the days with Bluez4 and will require some updating to work with Bluez5 but I think they can make good examples or even be the start for the BT file sharing implementation we will need).

I think the OBEX file sending/receiving will definitely needed to be implemented in the system, and with that can be unconfined/trusted. That said, we might want to allow apps doing so too, but I think that's not sooo critical for a start.

The RFCOMM/L2CAP on the other hand is really something that Apps will want to use. That's the basis for things like multiplayer BT games, BT remote controlling stuff or also connecting to any other BT enabled gadget.

When it comes to Low Energy, my experience gets a little thinner, but looking at the QtBluetooth backend implementation it seems to be the same as RFCOMM. It requests a L2CAP socket (in form of a file descriptor) exchanges data through that.

Status changed to 'Confirmed' because the bug affects multiple users.

It sounds like the content-hub portion can just be handled with changes to content-hub and the app doesn't need anything new.

OBEX file sending/receiving sounds like it doesn't need app policy at this time. That service can just run trusted (though it would be nice if it ran confined with a system profile since it will be handling untrusted input).

I need more details on RFCOMM/L2CAP and Low Energy-- how are apps supposed to use this? What would apparmor policy for apps look like? How do apps get access to the devices-- are they files in the filesystem? Are they virtual kernel devices? How do apps find out about them? How are they assigned? How can we integrate the trust-store for this sort of thing?