Initial implementation of merge-able transitions

This adds a couple things to support "merging" of transition
animations in shell.

1. Moves the finishing surface operations into a transaction that
   gets sent to shell. This does a couple things: it complies with
   the contract we have where during a transition, only the player
   should touch relevant surfaces; and, it makes it so that the
   player can merge the transaction with other ones.

2. Keeps a queue of "pending" transition animations in shell and
   either merges them or runs them serially.

3. Any transition that becomes ready while another is playing will
   first be sent to the playing handler to give it a chance to
   "merge" the incoming transition.

There are 3 expected responses to overlapping transition animations:
1. Cancel the currently playing transition and immediately start
   the incoming one. This can be achieved by having the currently
   playing transition cancel itself (ie. immediately finishing) when
   a merge request comes in. Then the rest of the shell transition
   logic will immediately start the next transition.

2. Queue up the incoming transition to play once the current one
   finishes animating. This is basically the default as long as
   the current transition simply rejects/ignores merge requests

3. Merge the incoming transition. This is achieved when the
   currently playing transition actually does some special logic
   to handle the incoming transition. It then calls the finish
   callback for the incoming transition (before it finishes its
   own animation) to indicate that it has been merged (or "consumed").
   Basically, any time the finish callback for a transition is
   called before a pre-ceding transition, that transition is assumed
   to have been merged.

Bug: 183994113
Test: atest ShellTransitionTests
Change-Id: I3cb54e221d57642306ddf15827c21d8881b014d0