bluetooth: Use the same DeviceMap as BlueZ 5

As we want to keep track of changes in org.bluez.Device's objects,
it is very convenient that we keep GDBusProxies for each device.

And the plan is to have the key of the map to be the object path of
the device, so when an signal is emitted it can be immediately
recognized which device has changed.
bluetooth: Keep track of org.bluez.Device objects

The process is more involved for BlueZ 4 than for BlueZ 5. Before we can
notify upper layers that we have a new device we need at least to have its
address, for BlueZ 4, this requires that we send a D-Bus message to get its
properties.

For this process we keep a map of object paths to addresses, so when a
change is detected on one object path, it can be detected and we can
send a message to the JS side.
bluetooth: Implement getDevice() for Adapter

This method returns an BluetoothDevice from the list of known devices.
bluetooth: Fix not adding a device to the known devices list

When the device is already known to BlueZ, an DeviceUpdated() message
will be sent, and it means that the device should be added directly
to the known_devices list that is kept.

One example of when this could happen is when there are already paired
devices when the extension starts.
[Systeminfo] Add SIM property support
[SystemInfo][BUILD] Using capi-system-info for Tizen mobile
[SystemInfo][LOCALE] Using capi-runtime-info for Tizen mobile
[SystemInfo] Minor fix to avoid using assign() of std::string
[SystemInfo][BATTERY] Using vconf for Tizen mobile
Merge pull request #88 from qjia7/master

[Systeminfo] Add SIM property support
[SystemInfo] Implement WIFI-NETWORK module
[SystemInfo] Use comprehensive function name instead

s/StartListen/StartListening
s/StopListen/StopListening
Merge pull request #91 from legendlee1314/master

[SystemInfo] Implement WIFI-NETWORK module
Merge pull request #92 from vcgomes/bluetooth-get-device

Add tizen.bluetooth.getDevice()
Merge pull request #84 from fyraimar/master

Implement build API for Tizen mobile using capi
[bluetooth] trivial: avoid known_devices if error
[bluetooth] implement destroyBonding API
[demo] bluetooth implement unpairing calls
Merge pull request #90 from dorileo/tizen-bluetooth-clone

[bluetooth] destroyBonding API and demo updates
bluetooth: Fix notifying the same device multiple times on discovery

With the changes to what information we keep on the C++ side of the
extension, there was a side effect that the same defice was reported
multiple times on the ondevicefound() Discovery callback.

The fix is to handle marking the device as "new" on the JS side, as it
already has the known_devices and found_devices list, so it can take the
correct decision.