HfpClientInterface: always ack on |*StreamingRequest|

The audio HAL expects a response from the BT stack on start/suspend.

Since SCO connections can be opened on demand for either directions
(w.r.t. audio streams), but closed for both directions at once, it can
be tricky to try to validate which suspend acks should be sent to which
client (e.g., there could be a race between the two start requests and a
suspend in between).

Here we enfore acks to the listeners of both directions on SCO
connection start/suspend.

Test: verify BT audio works
Test: m Bluetooth
Bug: 349290628
Bug: 315234036
Flag: com::android::bluetooth::flags::is_sco_managed_by_audio and HFP

Change-Id: I5b19e763d0a663c2b8234638f43fb4fb2da43fbc