ohos: integrate bluetooth local device

Implement QBluetoothLocalDevice on OHOS - adapter state, host mode, the
local device name and the scan mode - with the platform layer it needs
added under the ohos subdirectory. Always pass a scan mode duration of
0 so the adapter stays discoverable permanently, which leaves
HostDiscoverableLimitedInquiry without a timeout: observed on device,
the adapter stayed discoverable for the whole 100 s the probe watched
it and reported itself back as HostDiscoverable, so a limited inquiry
request counts as satisfied by either mode. Observe the OHOS
'scanModeChange' event, so that a host mode change is reported even
when only the scan mode changes while Bluetooth stays powered on.

Track a host mode request until the adapter settles on it. HarmonyOS
switches the adapter asynchronously and reports the intermediate
TURNING_ON and TURNING_OFF states, and reaching a discoverable mode
needs the scan mode set once the adapter is already on, so one call
cannot satisfy setHostMode(). While the adapter is unsettled wait for
its change event under a single deadline; once it is settled but the
request is still unmet, re-issue every 500 ms. Give up 20 s after the
request was made, and grant a fresh 20 s once the power switch lands,
because that switch waits for the user. Ignore a rejection when the
pending request issued no switch of its own, so that an answer to an
abandoned switch, or to one another instance asked for, cannot end it.

Switch the adapter with enableBluetoothAsync() and
disableBluetoothAsync(). HarmonyOS raises a system dialog the user must
answer, and the sync enableBluetooth() and disableBluetooth() calls
return before that happens, so a declined switch would only surface as
the give-up deadline expiring. Only the async variants document 2900013
"The user does not respond" and 2900014 "User refuse the action"; the
promise is created inside the JS thread crossing and its rejection is
delivered to the Qt thread afterwards, so nothing waits for the user and
the pending host mode request is resolved as soon as the answer arrives.

Handle only the JS business errors that describe a condition outside the
application's control - the permission revoked after the check, the
service stopped, Bluetooth disabled, the operation failed - and abort on
anything else. An undocumented code, or an error object without a
numeric code, means the platform does not behave as documented, and
carrying on would build a degraded state on an unknown failure. Read the
local device name only while the adapter is on, because with bluetooth
off getLocalName() was observed on device throwing 2900008, a code no
HarmonyOS header documents for it: guarding on the adapter state lets
allDevices() report nothing instead of ending the process.
Report MissingPermissionsError through errorOccurred() by checking the
permission in the ohos proxies, which emit missingPermission(), keeping
the backend free of Qt error types.

Base the implementation on the following assumptions:
- there is only one local Bluetooth adapter,
- the local adapter address cannot be taken, so
QBluetoothLocalDevice::address() returns an empty address,
- connected devices are not implemented due to no service connection
support at this moment,
- QBluetoothLocalDevice::allDevices() should return all local hardware
Bluetooth adapters, but HarmonyOS exposes no enumeration API: report the
one adapter whose name the platform answers with, carrying no address
since it cannot be obtained, and report nothing at all when that read
fails rather than fabricating an entry,
- implement the pairing interface at a later stage of the Bluetooth
integration.

Task-number: QTBUG-147192
Pick-to: 6.12
Change-Id: Ib2c0744dffc5ec3ef371278715aa12156d557c21
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Zbigniew Chyla <zbigniew.chyla@qt.io>