Transition flags for Keyguard un/occlude/cancel

Final keyguard state is computed in KeyguardController and passed
through Transition flags to SystemUI for occlude status as well as
(previously) visibility during unlock.

The occlude state cannot be derived only from ChangeInfo items in the
transition.

Example 1: b/284096414 where an app launches two activities, one opaque
and the second translucent. Closing/unoccluding the translucent activity
leaves the opaque activity on screen. This should not be recorded as an
unocclude, but all Keyguard sees in the Change diff is an OCCLUDE
activity closing and nothing new opening.

Example 2: b/282672298 in which a shared-element return transition from
Photos to Camera generates two separate transitions: one for re-opening
Camera, and a second for closing Photos. Because the final transition
was for a closing OCCLUDE activity on its own, all Keyguard could
interpret this as was a request to unocclude the keyguard and play the
return-to-keyguard animation.

These cases are fixed by the final state being sent after the transition,
but the intermediate animation was wrong and showed the lock screen
views for a few hundred milliseconds.

We also introduce one more flag in opposition to KEYGUARD_GOING_AWAY,
which is the flag KEYGUARD_APPEARING. This is used to wrap up
swipe-to-unlock interactions which end with the device locked, since
swipe-to-unlock optimistically generates a full transition for the
unlock and to avoid jank we have to merge an inverse transition back in.

Bug: 284096414
Bug: 282672298
Fix: 282302169
Fix: 282291585
Change-Id: Ib2c7acdace63729dd52711e47c8cc481eac45ebe