GitLab

This CL implements an imperfect but serviceable-for-now transition animator
used when entering the tab grid.

Most of the logic for building and running the animation is in the animator
class. However, to set the animation up, the tab grid needs to vend some
information. This is done through the TabGridTransitionStateProvider protocol,
which the TabGridViewController implements.

Most of this information is handled by the -transitionGridLayout method, which
returns an array of dictionaries with predefined keys. Some of the values are
collection cells, which GridCell provides (a grid cell can now provide a "proxy"
version of itself for this purpose). These are then used to build the animation.

Because the grid animation really needs to happen *behind* the grid toolbars
to look right, the state provider protocol includes two somewhat janky methods
to expose views to make this possible -- a view to add the transition cells to,
and a view in that view to put them above. The implementations of these methods
return the TabGridViewController's view, and it's scroll view, respectively.

This means the animator is adding and removing stuff from the view hierarchy
of a view controller, which isn't ideal. The alternative is to also proxy the
tab grid toolbars in the transition animation, which will require a bit more
plumbing.

There are a number of fit-and-finish cleanups that need to happen; a separate
task bug has been created for them.

Bug: 804538
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Ifde8bb27b70ce350e40eeb1e1b14675579f84d7d
Reviewed-on: https://chromium-review.googlesource.com/957039
Commit-Queue: Mark Cogan <marq@chromium.org>
Reviewed-by: edchin <edchin@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542757}