Prioritize some broadcasts ahead of strict FIFO

User-interactive event flow and broadcast priority classes both suffer
from priority inversion issues with strict FIFO dispatch policy:
existing queued deliveries might require significant time to complete
dispatch, with the resulting delivery latency of the interactive or
foreground-priority messages leading to poor user experience.  To
address this issue, we introduce urgency-base queueing policy, with
"urgent" broadcasts placed ahead of ordinary ones in the recipients'
pending queues.  A broadcast is currently considered urgent when:

* the sender has marked it FLAG_RECEIVER_FOREGROUND, or
* the sender has marked it as "interactive", or
* the broadcast was issued by an alarm triggering

AND

* the broadcast is only going to a single receiver

That final restriction prevents certain kinds of interference with
ordered broadcast delivery and completion semantics.

"interactive" is a new BroadcastOption applied when the broadcast
issuance is in response to a direct user interaction, i.e. when
timeliness of delivery is directly perceived as a responsiveness issue
by the user.  The canonical example of this is notification
interactions, though perhaps the concept might usefully be applied to
scenarios such as high-priority push message delivery.  For now its use
is restricted to system-internal callers.

Finite capacity for dispatch parallelism can currently cause priority
inversions even with the new queueing policy if all available running
slots are occupied with background-priority deliveries.  Addressing
this will happen in a follow-on CL.

Bug: 251902289
Test: atest FrameworksMockingServicesTests:BroadcastQueueModernImplTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueTest
Change-Id: I47813c2c6ca43559f39d701f104fa62527c7bc21