Send events from InputEventReceiver in order

When InputEventReceiver processes events, it tries to send the current
event right away. If everything succeeds, then it returns. If not, the
event is queued for later.

Later, when the looper wakes up, it will try to process the pending
events. It will process as many as it can, and will come back to process
them again later if not everything is done.

In this CL, we change the order of this operation: we enqueue the
current event at the back of the queue. We will then process the entire
queue (or as much as we can of it). This will ensure that all events are
processed in order.

It's OK to process the events out of order, but may be more natural to
process them in order. More importantly, this refactor helps reduce the
code duplication in the subsequent CLs, and ensures that there's only a
single place that calls 'sendFinishedSignal'.

Changes to 'setFdEvents' operation:
The function 'setFdEvents' checks if there are any changes to 'fd
events' before actually modifying the looper. We rely on this behaviour
to simplify the calls to 'setFdEvents'.
At the end of the function, if the queue is empty, then we set fd events
to 'input only'. There are no more pending outgoing events. This is a
no-op if the queue was already empty prior to the invocation.
If we are about to return WOULD_BLOCK, it means that the queue is not
empty. In that case, we would always set the events to input/output.
This would not call the looper api's excessively, but simplifies the
logic in processOutboundEvents.

This CL simplifies the addition of a new outbound event in the child CL.

Bug: 169866723
Test: adb shell monkey 10000
Change-Id: I167e0c54f79bb4d8b78ca8b7dc4f8c00c989c56f