Hold a wake lock while dozing when display updates are pending.

When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.

This patch is somewhat approximate but should be good enough for
most devices today.

Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock.  There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing.  However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).

Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.

Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350