Support transitions waiting during collection in parallel

This adds support for moving a transition to collecting
while another one is already collecting. For now, since
we don't have transactionalization in the rest of WM, the
transitions won't truly collect in parallel. Instead, the
transition which was previously collecting will be moved
into a "waiting" queue and the new transition will be the
primary collector.

This means that there is still only ever 1 transition
collecting WM changes AND that the transition *setup* is
still serialized. However, this allows multiple transitions
to concurrently *wait* for their collected members to
become ready. In practice, this waiting is what actually
takes time. The setup, itself, is usually already performed
with WM lock, so it is basically already serialized.

If a transition was moved to the waiting queue, it will
move back to collecting if the collecting transition became
ready first. This way, there is never a time where it
is waiting but not able to collect (this would create many
problems).

By default, we still serialize (queue) all transitions. We
currently hardcode the logic deciding whether a transition
will be allowed to collect in parallel. In this CL, none
are allowed since this is just providing the ability.

Since this decision logic is in WMCore, we need to communicate
it to Shell. This is done by assigning each transition
to a "track". A "track" is a set of transitions that must
run serially and in order. If a transition is parallel
with all other transitions (at animation-ready time) then
they will be assigned a new track. Otherwise, if it
overlaps with transitions from an existing track, it will
be assigned to that track. Lastly, if the transition
overlaps with transitions from >1 track, it will actually
be marked as SYNC which means that it can only run after
ALL OTHER transition animations finish. Theoretically,
this is overkill, but the effort to do something fancier
is not worth-it as it would be significantly more
complicated and there aren't really any situations where
it'd actually improve anything.

One last complication is how to deal with order-changes.
Since window order is a global property, we theoretically
wouldn't be able to collect anything in parallel. However,
by acknowledging that we still serialize *setup*, we can
build some reasonable rules around tracking this. Specifically,
we still record the "start" on-top state for each transition;
however, this change also records the "onReady" state once a
transition becomes "ready" (note that this is when it has
started and collected all the containers; NOT "animation-ready").

This way, if the transition moves to "waiting" and the next
transition actually changes order, we won't attribute those
order changes to the "waiting" transition since it can just
delta between its own ready-order and start-order.

To avoid double-reporting, we also capture the "last reported
order" globally whenever a transition becomes animation-ready
and sends the state to shell. Then, when calculating deltas,
the transition uses the last-reported order instead of its
start order if available.

Since WM is still a bit uncoordinated, to make sure we don't
accidentally drop any order changes, we will still always use
the "current" order (instead of the ready order) if there are
no other transitions waiting/collecting.

Bug: 264536014
Bug: 277838915
Test: atest TransitionTests
Test: existing tests -- this CL alone should be a no-op
Change-Id: Ib6707802a45edef60f85b391b544c1694729c2df