Fixed some timeout and lock reentrance issues with broadcasts.

When starting a broadcast, the ActivityManagerService posts a delayed
BROADCAST_TIMEOUT_MSG to handle timeouts.  If a premature timeout occurs,
we post a new BROADCAST_TIMEOUT_MSG to extend the timeout time for the
current receiver.  However, if the current receiver does timeout, the
message is consumed and no replacement is ever posted.

To fix the dropped timeouts, we track whether we have a pending broadcast
timeout message and setup a new one when we begin working on the next receiver.

As a last resort, performNextBroadcast contains code to detect whether
a broadcast appears to be hung (timeout handling failed).  If so, it
calls broadcastTimeout to cause it to timeout immediately.
However, performNextBroadcast is holding on to the ActivityManagerService
lock while doing this but broadcastTimout expected to be called
while the lock was not held since after updating the broadcast record state,
it calls appNotResponding.

To fix the unintentended lock reentrance, changed broadcastTimeout to
assume the lock is already held (and the callers ensure this) then
added code to perform the ANR asynchronously.

Renamed a few methods to add "Locked" suffixes where appropriate and added
a few comments for tricky areas uncovered during review.

Change-Id: I3cb5b06d6b6a4a338f32c0998db721f6acf3b082