BroadcastQueue: misc fixes before dogfooding.

Many test suites rely on broadcasts being processed quickly, and
there's a wide spectrum of use-cases, where the sender and/or the
receiver are being actively "instrumented".  This change adds logic
to make sure that no delays are applied in these cases.

Also add a counter for the recently added "interactive" flag, since
that's a signal that no delays should be applied.

Update getPreferredSchedulingGroupLocked() to match the logic we
use for selecting an ANR timeout duration, by only using the
"default" scheduling group for foreground broadcasts.  (Future
changes can expand this to "interactive" broadcasts if desired.)

Offer to deliver "resultTo" for non-ordered broadcasts, which will
be needed as part of upcoming BOOT and SCREEN changes.  Similar to
above, this is yet another case where no delays should be applied,
to ensure the "resultTo" doesn't get stuck waiting hours behind a
frozen or cached app.

Update KEY_DELAY constants to not use HW_TIMEOUT_MULTIPLIER, since
these are delays, not timeouts.  (Applying the multiplier causes
tests failures due to delaying too long on cloud devices.)

Fix obscure bug where callers were able register receivers without
providing an IApplicationThread; we need that to find the relevant
ProcessRecord for things like OOM adjustment, unfreezing, and more.

Bug: 253906105
Test: atest FrameworksMockingServicesTests:BroadcastRecordTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueModernImplTest
Test: atest Launcher3Tests:AddConfigWidgetTest
Test: atest CtsWindowManagerDeviceTestCases:ActivityVisibilityTests
Test: atest CtsActivityManagerBackgroundActivityTestCases:BackgroundActivityLaunchTest
Change-Id: I3424da03655457f58d66df761f63fd37ea2c9391