Put broadcast timekeeping on its own thread

Broadcast handling has fairly tight real-time / interactivity
requirements.  However, some key parts of its processing have had an
implicit dependency on the latency behaviors of shared looper threads
within the system process.  In practice this means that it's sensitive
to the behavior of unrelated parts of the OS, and in particular parts of
the system that perform long-running or otherwise "slow" work on that
shared looper thread, inadvertently DOSing broadcast delivery.

In order to tightly control the latencies and dependencies around
broadcasts' asynchronous processing, it is now using its own dedicated
thread for these operations instead of the shared Activity Manager
looper.

In addition, the framework coretest broadcast tests turned out to have
issues.  They were not properly up to date with respect to implicit
broadcast delivery policy, and furthermore had been copy/pasted from a
starting point that used multiple packages in tandem, so expectations
about permission policy no longer held true.  These issues have all been
fixed, and the BroadcstTest suite passes both before and after the
looper changes here.

Bug: 177396523
Test: atest android.app.activity.BroadcastTest
Test: atest CtsOsTestCases
Change-Id: I95501aaa458793a258e429b540c7ed9e8e6ba355