Fix faulty semaphore in CallAudioCommunicationDeviceTracker

The existing logic in CallAudioCommunicationDeviceTracker was using a
semaphore in order to only allow one thread to access the
(set/clear)CommunicationDevice functionality. However, the existing
method of using tryAcquire doesn't guarantee atomicity. If a permit
cannot be required, the computation would still proceed uninterrupted
which defeats the purpose of using semaphores.

Instead, use a lock instead so that the thread will wait until the lock
can be acquired. This is a simpler solution to a more robust solution to
using a SingleThreadedExecutor (which could be leveraged to preserve
order). However, that fix would be much more riskier in terms of
complexity and introducing regressions from potential race conditions.
We can consider trying to improve this solution for a future release
instead.

The root cause for this bug was not a timing issue; it was because we
were trying to disconnect BT as a result of processing CONNECT_BT with a
null address even though there was already a device connected. This is
denoted as a switch of BT devices so Telecom tries to disconnect BT
before connecting the new device. However in this case, the device
remains unchanged. This logic should be modified to take this into
account so that switchingBtDevices in BluetoothRouteManager is computed
correctly. This was also causing switching from a wired headset to LE
audio device to fail in the scenario where we try to connect to an
arbitrary device (resulting in a null address). Because the address
stored in the state is non-null, switchingBtDevices would equate to
true, so Telecom would disconnect any existing BT device. However, this
fails to take into account if the arbitrary address that we compute ends
up being the same device that's stored in the state.

Bug: 333751408
Bug: 337094096
Test: Manual with toggling on/off bluetooth during call
Test: atest TelecomUnitTests
Change-Id: I010dde219e414ba50f4527482137ba47ee0d4cab