Rm SynchronousResultReceiver usage

TL:DR;
revert aosp/1927380
revert aosp/1927379
+ revert all newly added SynchronousResultReceiver usage

----

A bit of history is needed to understand this change.
Before android T, the service binder were using Binder.allowBlocking in
order to silence warning when a system server thread was making a
blocking call into the Bluetooth.

When moving Bluetooth to an apex, we had to remove the allowBlocking
call as it was an hidden API. Since Bluetooth intend to be a mainline
module, it couldn't call it anymore.

This result in past me (*sick* I know who to blame) that create a
workaround for the blocking call: The SynchronousResultReceiver ! Yeah !
The intention was as follow:
The call would be oneway, so aync and non blocking, but the caller will
voluntarily wait on a future that timeout after 3 secondes (or 5
initially). Making the call "temporarily blocking".
In case Bluetooth was in a dead lock, the whole system server will not
freeze.

Neat? No…

This has a drawback, now, instead of one binder call, we are making
2 calls, one in the initial direction, one to return the value into the
future. In case of a heavy binder usage, the call can get lost (and
spoiler it happened).
The second drawback is that we are still making blocking call in the
end, but we completely silenced the warning now. So we don't even know
where to look at to fix them

Please review carrefully (I am too) as the revert were 2+ years old, and
a lot of conflict were manually resolved

Bug: 324420709
Test: mmm p/m/Bluetooth | All unit binder test are welcome here
Flag: Exempt, mechanical refactor (Huge, but mechanical)
Change-Id: Ie697ec09ce845409cc46f3e807be06884fd7c871