BroadcastQueue now uses scheduleReceiverList

Bug: 253906553

Convert the broadcast queues to the new scheduleReceiverList API in
IApplicationThread.  The changes are as follows:

 1. The ReceiverBatch class is created to handle the arguments to
    scheduleReceiverList.  The class has additional functionality in
    preparation for allowing batches of more than one receiver.  The
    ReceiverBatch class is essentially bookkeeping: it maintains lists
    of information for a client.

    The ReceiverBatch class has a single() method that does everything
    necessary to dispatch a single manifest or registered receiver.

    In normal operation, the ReceiverBatch class uses object pools and
    does not do any allocation after it has been instantiated.  There
    is a test mode that always allocates new objects.  See the notes
    on BroadcastQueueTest.

 2. BroadcastQueueImpl and BroadcastQueueModernImpl each contain an
    instance of ReceiverBatch, size 1, and use that instance to invoke
    scheduleReceiverList.

 3. BroadcastQueueTest is modified to test against the new thread
    API.  There are changes in the support methods in the class.  The
    intent is that the actual test code looks like a textual rewrite
    rather than a logical rewrite.

 4. BroadcastConstants includes a MAX_BROADCAST_BATCH_SIZE, which is
    set to 1.  This is not required for this CL but is a stake in the
    ground to minimize future merge conflicts.  This constant will be
    increased when the modern queue supports more than one receiver in
    a batch.

 5. BroadcastRecord has two new per-receiver attributes: the transmit
    group and the transmit order.  These are initialized in the
    ReceiverBatch.recordBatch() method (which is not called in this
    commit).  Again, this is a stake in the ground to minimize future
    merge conflicts.

There is no behavioral change in this commit.

Test: atest
 * FrameworksMockingServicesTests:BroadcastQueueTest

Change-Id: I543092cdd68a979fb466a2156c251c6c4f024b61