All keyguard occludes go in-band with transitions

Previously the logic was as follows:

 - If keyguard is locked, send occlude in a transition
   - And send a direct update after all transitions finish
 - If keyguard is not locked, send occlude directly

This had a race if some activity decided to occlude the keyguard and
request its dismissal at the same time, since an occlude transition
could be generated followed by a direct update. The direct update is
applied instantly but the occlude transition is not so it could run
later and since there is no sequencing between the two the keyguard
service could still end up confused.

Now although we still send the direct updates, they wait to go out until
SystemUI has reported to us that it finished handling all the active
transitions. This prevents racing ahead of enqueued transitions. To
prevent racing behind future transitions we rely on the guarantees
about ordering of oneway RPCs on the same IBinder.

Test: atest CtsWindowManagerDeviceTestCases:KeyguardTests
Fix: 284811687
Change-Id: I6c369c922170a5c9aab96a5060089c1b6fb8fd85