Compare the NDef records without using qHash

It seems Windows produces a different hash value compared to
other platforms.

Change-Id: I73669894d63ffca08dbc6ed010e923050a0c8e8f
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Bluez5: QBluetoothLocalDevice becomes invalid if adapter disappears

Bluez5 supports org.freedesktop.DBus.ObjectManager interface which
permits monitoring of removal/addition of Bt adapters. This permits
the invalidation of the current QBluetoothLocalDevice instance. Once the
instance is invalid, it will remain invalid. Otherwise we could have a
switch of the adapter without the developer noticing it because the next
Bt dongle could get the same interface path. This would
violate the sense of identity that is attached to a
QBluetoothLocalDevice instance.

Task-number: QTBUG-38399
Change-Id: I007278ff1f94c48d6e6902959132088858b0d011
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Don't stop processing of Bluez services if one service is invalid

This is a regression introduced during the Bluez5 port. During the
service xml parsing we may encounter an invalid service info. This does
not mean the next one is invalid too. This bug caused the service
discovery to abort.

Change-Id: If51e0f898d83e99ba0a279c13ccaa3e5947bb6bf
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Bluez5: Add service (un)registration support

The Bluez5 DBus API does not permit the selection of the
local Bt adapter when registering a service. This means that
if the local device has two Bluetooth adapters the service will be
advertised by both adapters. This leads to cases where
the QBluetoothServer::listen() call binds the socket on one adapter
but the remote device tries to connect to the other adapter.

For now this is an acceptable behavior since it is rather rare to
have two local adapters at the same time. A potential future fix is
tracked by QTBUG-39012.

Task-number: QTBUG-32085
Change-Id: Ibb24edc5b9d1c25a005aedd98f6fc5d0d11b60f8
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Bluez5: Simplify lookup of default adapter

Change-Id: I59aa5241d33191a8ca8cc167263b63b024f52754
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
Avoid empty service names

Bluez doesn't seem to know the service class uuid 0x1200 which seems
common on BB10 devices. Ensure that we set a name if Bluez did not
provide a name. This was made possible by the recent addition of
QBluetoothUuid::serviceClassToString(..).

[ChangeLog][QtBluetooth][QBluetoothServiceDiscoveryAgent] Fixed
cases where Bluez doesn't provide service names for given Bluetooth
service class uuid.

Change-Id: Ife56ab878f70ca6226e907f59972368c79318bec
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>