Barrier only messages shouldn't prevent the idle handlers from running

If the queue just consists of barrier messages the idle handlers will
not been executed, cause mMessages isn't null. Barrier messages aren't
real messages and shouldn't be included in this test. They are an
internal feature of the message queue and they just happen to be
implemented as normal messages without a target.

This fix checks if the queue only consists of barrier messages and if so
(or the queue is empty) it executes the idle handler callbacks. If the
queue consists of a barrier messages followed by any normal messages the
old behaviour still applies.

The bug can be seen if somebody calls Instrumentation.waitForIdleSync()
and the application changes the layout on every frame, like in
android.app.cts.ProgressDialogTest -- testShow3 on certain platforms.
The progress bar in indeterminate mode repaints the spinning circle on
every frame. This seems to trigger scheduleTraversals() in ViewRootImpl,
which itself inserts a barrier into the message queue.

Other people noticed this as well as seen here:
https://code.google.com/p/android/issues/detail?id=82046



I could repo this using the test case from the bug report on a Nexus 5.
Changing the testShow3 CTS test so that there is a Thread.sleep(3000);
right before mInstrumentation.waitForIdleSync(); also reproduce it on a
Nexus 5.

It is also worth to mention that this really depends on the type of
animation. Removing the minimum sdk version from the test application,
switches the animation to the old version of the spinning circle. This
seems to include lesser frames and therefore doesn't trigger this bug.

Change-Id: I2dfe97ed92ab19e9f488014e8f591f17ac40c76c
Signed-off-by: Christian Poetzsch <christian.potzsch@imgtec.com>