SurfaceFlinger: Check both queues in transactionFlushNeeded

transactionFlushNeeded is called from handleMessageTransaction to
deal with an edge case in timing. First note that we are not holding
the state lock in handleMessageTransaction, and so a binder thread
could be adding transactions to the queue. If a Binder thread
adds a transaction to the queue in-between the calls to
flushTransactionQueues and handleTransaction then its
addition of the eTransactionFlushNeeded flag will be cleared out
when handleTransaction consumes eTransactionMask. The code in
the transactionFlushNeeded conditional was added to handle this
condition, but transactionFlushNeeded was only checking the
pending transaction queue. If there were a a transaction added
to the mTransactionQueue (binder thread->main thread communication
queue) during this interval, we wouldn't pick it up from
transactionFlushNeeded and we wouldn't reapply the flag. Recent
changes seem to have agitated this condition and we are receiving
a lot of dogfood bugs, so deploying this as a hopeful quick fix. A
follow-up CL will rework this brittle flag system with something
easier do understand.

Bug: 180194022
Test: Existing tests pass
Change-Id: I0b1cb7acf7576e38ea076c7f3b921cbce25775bc