Avoid invalid state in search/discovery queue state machine

The sequence of events in the state machine that causes the bug is as follows:
- We start a search, and move from the IDLE state to the SEARCH_ACTIVE state.
- We initiate a pairing request, that sets pairing_cb.state to BT_BOND_STATE_BONDING.
- We cancel the search, returning to the IDLE state.
- We then try to start a second search. In BTA_DmSearch, we check if we are bonding, and if so enqueue the request.
- But we remain in the IDLE state! So we never dequeue the search request, getting us into the stuck state.

This CL fixes the issue by removing the *_QUEUE_* events, making the state machine the single arbiter for whether a request should be executed or queued. In particular, for the above scenario, the SDP request will queue behind the second search request, if it arrives afterwards, *even if* bonding has already begun. This prevents us from getting in a stuck state.

I believe that this is safe since we preserve the invariant of only ever have one request going through at a time, but manual testing is needed to be certain. The preservation of this invariant also means that we should not regress b/237352700, though I am unable to test that.

Note that this CL is stacked on top of the revert^2s at ag/19019716, so it will exhibit merge conflicts until those CLs are landed.

Bug: 230277335
Test: Manual, using the repro steps from the bug thread.
Tag: #stability
Ignore-AOSP-First: Hotfix for T

Change-Id: I74e83964995b10f4bee35bae3182ec482bdedb39