Apply negative delay to "urgent" broadcasts.

When choosing which "runnable" process to promote into a "running"
slot, we currently use a single scoring dimension of a "runnable at"
timestamp, and always start with the longest-waiting process.

However, in the case of a process with urgent broadcasts, we could
still end up waiting behind many other non-urgent processes that
just happened to enqueue themselves earlier.  (This is particularly
evident with BOOT_COMPLETED broadcasts.)

Future changes will improve execution and starvation guarantees
in this area, such as by reserving certain "runnable" slots for
processes with urgent work.

This change also improves test flakiness by treating broadcasts sent
from the shell as if the sender was "instrumented", since many tests
rely on sending broadcasts through the shell.

Bug: 253906105
Test: atest FrameworksMockingServicesTests:BroadcastRecordTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueModernImplTest
Change-Id: I12f49d4135d3cab18dcadb42f37a9367e8638585