AudioService: refactor communication route control

Audio routing for communication use cases (cell, video and VoIP calls)
is controlled by separate APIs: setSpeakerPhoneOn(), startBluetoothSco()
and stopBluetoothSco().
Requests for speakerphone and bluetooth are managed by separate client
stacks although in the end they control a single routing state in audio
policy manager, which creates problems in case of conflicting requests
and race conditions.
This CL refactors the implementation by regrouping the Bluetooth Sco and
Speaker client stacks into a single one. This makes sure that no
conflicting routing request exist for a given client.
It also makes handling of race conditions and prioritization between
clients easier.
Finally, it prepares the introduction of a new API that will be the
single entry point for communication route control.

Also in this CL:
- Option to enable more debug log for communication route
- Fixes in BtHelper.receiveBtEvent()
  1) Fix intent broadcast missing in case of transition from external
  activation to internal activation.
  2) Do not clear SCO requests when SCO audio is disconnected: this can
  happen because current active communication route request is different
  from SCO but pending requests must stay in the stack.
  3) Do not clear SCO requests when the audio mode owner changes. Any Active
  communication route requested by new audio mode owner will be honored
  and pending requests will be restored when mode owner changes again.

Test: regression tests with cell and VoIP calls

Change-Id: If9d2f24b9def78ccd791294ed42d95ce30f0ba8b