Fix pip update transaction out of order

When an animation is playing, PipAnimationController#onAnimationUpdate
is called with the fraction of the animation progress. This fraction is
used to calculate a scale value (in a matrix), which is applied in a
transaction to the pip surface. This scaling is invisible to WM core, so
the bounds of the pip surface are still the bounds before the animation
began. In SF, those bounds are scaled and drawn. When the animation is
finished, onAnimationEnd is called. onAnimationEnd is special, because
it finishes the resizing and sends the updated pip task bounds to WM
core in a WindowContainerTransaction. The WindowContainerTransaction is
applied separately by WM core.

Additionally, the transactions forged by onAnimationUpdate are
not applied immediately. In each onAnimationUpdate, the pip surface
transaction is applied in a SyncRtSurfaceTransactionApplier (together
with the transaction for the pip menu), which waits until the next draw
is complete and then merges the pip surface transaction into the global
frame transaction. In onAnimationEnd, however, the pip update is not
applied in a SurfaceControl.Transaction, but a
WindowContainerTransaction is sent to WM core, which applies it at some
later point. If the pip surface transaction from the last
onAnimationUpdate is merged+applied after the WindowContainerTransaction
is applied in WM core, then the two transactions are committed out of
order and the pip surface ends up in this weird state, where an extra
scale was applied to it.

To address this, we delay the onAnimationEnd to the next frame, which
adds enough time to let the last onAnimationUpdate transaction be
applied. We do this only when the PiP transaction has to be synced
with the PiP menu drawing, because the synchronization between the
two is what causes the last onAnimationUpdate transaction to be
applied with a delay

Bug: 228317396
Test: manual - change pip aspect ratio several times
Change-Id: Iaf4005b34b63ab7a123e508ace80f966014a0805