Ensuring multi-window callbacks contain new configuration and are in order

- This CL has two main changes:
  1) It modifies the activity multi-window and picture-in-picture mode
     changed callbacks to provide the configuration of the activity with
     the mode applied.
  2) It modifies the order in which the multi-window and picture-in-picture
     mode callbacks are made, to ensure that when going in and out of
     picture-in-picture: first PiP, then MW, and then the config change.
- Previously, the ordering of the two callbacks was inconsistent.  When
  calling moveActivityToPinnedStack(), we reparent the task into the pinned
  stack (triggering the picture-in-picture mode change), followed by the
  resize animation (causes configuration changes).  Inversely, when we
  expand the task to fullscreen (and not just remove it), we run the
  animation first, which resizes the task to the final size (causes
  configuration changes) then reparent after the animation completes
  (triggering the picture-in-picture mode change).

  In this CL, we ensure that for both the transition in and out of PiP, we
  defer to the bounds animation to trigger the PiP mode change.  Normal
  calls to reparent or adding a new task are unchanged.  When the PiP
  mode change is called from the animation, it provides the final target
  bounds which we use to calculate the target configuration of the activity
  for the callback.  If the bounds animation is interrupted, an update will
  also be scheduled if we change the fullscreen state we are animating to.

  To work around the issue where we are scheduling MW/PiP mode changes in
  both the animation and the configuration change, we also now keep track
  of each state internally in the ActivityRecord.

Bug: 36099777
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testConfigurationChangeOrderDuringTransition

Change-Id: I03513bc3a4d4a72c250983f22f079ce9d7a2cb40
Signed-off-by: Winson Chung <winsonc@google.com>