Correct animation glitch for pinned stack.

During an auto-PiP operation it can be
such that the pipped activity "isWaitingForOpening".
This is due to the visibility toggling to hiddenRequested,
and then back to visible, which causes it to enter mOpeningApps.
Logic in display content, prevents updating the surface boundaries
while we are in this waiting for opening state. This causes the animation
to jank as the top left corner will not move. The claim made
by the comment is that certain animations may have not "processed
their initial transformation".  So we ignore this "waiting for opening"
state if the app transition is a dummy animation, in which case we have
no transformation anyway.

Bug: 36821017
Bug: 35396882
Test: Enter PiP from YouTube, make sure top left corner moves smoothly.
Change-Id: Ia8519fe3c955f2ac80151b851c219d6ddbd26fed
(cherry picked from commit 0c901695e6770bab6a7d247e1d8ce431fc3ca955)
diff --git a/services/core/java/com/android/server/wm/DisplayContent.java b/services/core/java/com/android/server/wm/DisplayContent.java
index 4ebf1fc..15aedd5 100644
--- a/services/core/java/com/android/server/wm/DisplayContent.java
+++ b/services/core/java/com/android/server/wm/DisplayContent.java
@@ -665,7 +665,8 @@
                     }
                 }
             }
-            if (!winAnimator.isAnimationStarting() && !winAnimator.isWaitingForOpening()) {
+            if ((!winAnimator.isAnimationStarting() && !winAnimator.isWaitingForOpening()) ||
+                    winAnimator.isDummyAnimation()) {
                 // Updates the shown frame before we set up the surface. This is needed
                 // because the resizing could change the top-left position (in addition to
                 // size) of the window. setSurfaceBoundariesLocked uses mShownPosition to