The same as AlwaysCompletePerformance but the exact opposite.

Also, replace places that use the term "create performance" with
"create performance controller".

Primarily, this rearranges how listeners are handled internally by the
various PerformanceView classes so that there's not so much redundancy.

It also fixes ReversePerformance and ProxyPerformance to not leak.
Previously, they never unhooked their listeners, so they'd leak until
the entire chain of performances was killed. Now, they unhook as soon as
they themselves have no listeners left, which is more idiomatic.

For those times when you want to do something as you move away from a
route into the next one, as well as when you move into it from the
previous one.

The names are probably less familiar, but more consistent:
- FrameCallback: a callback that is relative to the frame and wants the
  frame offset (a duration) as argument.
- addXFrameCallback: adds the given callback to the internal lists/maps.
- scheduleXFrameCallback (currently only X = ""): add the callback, but
  also trigger a new frame.
- handleX: the method that is invoked when the event-loop or the frame
  calls into the scheduler.
- ensureXYZ: ensure that the callback happens.
  Unfortunately there is the ambiguity between a "callback": it can be a
  closure, or the action of doing a callback, so we end up with:
  ensureBeginFrameCallback, and ensureEventLoopCallback, where
  "callback" means the action of being called back.

This change will let us remove the tracing interface from dart:ui and also
makes these timeline events show up in Observatory.

Fixes #447

PageRoute is now MaterialPageRoute.

This also changes the following:

- Now the HeroController is a Navigator observer, rather than a feature
  of HeroPageRoutes, which are gone. This means heroes can work between
  any kind of ModalRoute now.

- ModalPageRoute is moved from modal_barrier.dart to routes.dart.

- It allows routes to opt-out of their modal barrier being a shortcut to
  popping the route.

- Features of PageRoute that aren't Material-specific get promoted to
  ModalRoute features: storage, the subtree key, offstageness...

The AnimatedModalBarrier is still a ModalRoute feature.

In this approach, the hero support is layered on top of the basic navigator
functionality.

We still use special-purpose typedefs in the gesture code for symmetry with
other gesture callbacks.

Fixes #1827

These new PerformanceView classes are transforms over PerformanceViews.
The first is a cheap way to tell code that expects a performance to not
animate after all, and the other is a way to replace a view of a
performance going in one direction with a view of a performance going in
the other direction.

See also https://github.com/flutter/engine/issues/1708

Provide a way to schedule a callback for immediately after the current
frame has been sent to the GPU thread. This is useful for times where
you want to immediately schedule yourself for another build or layout
because, for instance, you just displayed frame zero of an animation and
you want to use the metrics from that layout to set up the actual
animation to begin immediately, such that the very next frame is frame 1.

It turns out that an AnimatedContainer with a BoxDecoration would
start animating every single time it was built, whether or not the
container's decoration had changed.

(These are all the debugging-related fixes and trivial typo fixes that I
extracted out of my heroes branch.)

Fix rendering.dart import order.

Introduce a debugLabel for Performances so that when you create a
performance, you can tag it so that if later you print it out, you can
figure out which performance it is.

Allow the progress of a PerformanceView to be determined (but not set).

Allow subclasses of PerformanceView that are constants to be created by
defining a constant constructor for PerformanceView.

Introduce a debugPrint() method that throttles its output. This is a
test to see if it resolves the problems people have been having with
debugDumpRenderTree() et al having their output corrupted on Android. It
turns out (according to some things I read On The Internets) that
Android only has a 64KB kernel buffer for its logs and and if you output
to it too fast, it'll drop data on the floor. If this does in fact
reliably resolve this problem, we should probably move the fix over to
C++ land (where "print" is implemented) so that any use of print is
handled (avoiding the interleaving problem we have now if you use both
debugPrint() and print()).

Fix a bug with the debugging code for "size". In the specific case of a
RenderBox having a parent that doesn't set parentUsesSize, then later
the parent setting parentUsesSize but the child having its layout
short-circuited (e.g. because the constraints didn't change), we didn't
update the _DebugSize object to know that now it's ok that the size be
used by the parent, and we'd assert.

Also, allow a _DebugSize to be used to set the size of yourself.
Previously you could only set your size from a regular Size or from your
child's _DebugSize.

Add more debugging information to various Widgets where it might be
helpful.

Make GlobalKey's toString() include the runtimeType so that when
subclassing it the new class doesn't claim to be a GlobalKey instance.

Include the Widget's key in the Element's description since we don't
include it in the detailed description normally (it's in the name part).

Fix a test that was returning null from a route.

Add type annotations in many places.
Fix some identifiers to have more lint-satisfying names.
Make all operator==s consistent in style.
Reorder some functions for consistency.
Make ParentData no longer dynamic, and fix all the code around that.

Now that you import a top-level file for each layer of the Flutter
framework, within the framework we can use relative paths without being
worried about the copy/pasta problem we used to have.

This patch prepares us to create routes that control their performances more
closely.

This patch simplifies AnimationTiming and all the AnimatedValue base classes.
Also, make PopupMenu a stateless component because it has no state.

Fixes #1168

Fixes #1170

This patch converts drawer to using the "openDialog" pattern for managing its
state. Currently, the drawer entrance and exit animation aren't integrated with
the navigator's animation system because the drawer's animations can be stopped
and reversed, which the navigator can't yet understand. That means dismissing
the drawer via the system back button causes the drawer to be removed
instanteously.

Fixes #715
Fixes #1187

This patch folds the functionality from AnimatedSimulation into Timeline.

Rather than having two objects driving scrolling animations, we now have one
object, a Timeline, drive both scrollTo and fling animations. Using Timeline
instead of AnimatedSimulation paves the way to removing AnimatedSimulation
(which is now used only inside the animation library).

Finally, this patch also simplifies (and makes private) _TweenSimulation by
using AnimatedValue to do the math.

The only client wants a zero-based duration.

This patch prepares us to switch to using integers when handing off the
animation time from the engine to the framework.

We already forced hitting end on 1.0.

Fixes #1358

AnimationPerformance had some logic for supporting multiple variables
that was hardly ever used. ValueAnimation, a subclass, has logic for
handling a single variable. I've removed the logic for handling
variables from AnimationPerformance in favour of most call sites instead
using ValueAnimation.

Initial snap offset support for ScrollableWidgetList (and ScrollableList<T>) and ScrollableMixedWidgetList. If a ```toSnapOffset(scrollOffset)``` function is provided, fling Scrolls will coast to the returned value. If ```alignmentOffset``` is specified then fling scrolls conclude when toSnapOffset's value lines up with the Scrollable widget's origin + alignmentOffset. For example if the Scrollable widget's height was 200.0, and alignmentOffset:100.0 was specified, then fling scrolls would end with the value returned by toSnapOffset() lined up with the center of the Scrollable.

This approach to Scrollable snapping assumes that the layout of whatever the Scrollable contains is known at the outset. This is often true however a ScrollableMixedWidgetList may not know its items' sizes until they've been reached by scrolling.

This is a first cut at snapping support. Among the things that remain to be done:
- Scrolling limits trump snapping. Snapping should probably trump scrolling limits.
- Drag scrolls aren't snapped. This may be desirable so perhaps the feature should be controlled with a flag.
- Specifying alignmentOffset as a percentage would probably be more convenient.
- It would be nice if one could wrap items in a SnapOffset value like: ```new SnapOffset(0.5, child: myItem)``` to snap to the center of the item.

Updated the CardCollection example: snapping and fixed size items can be turned on/off with Drawer checkboxes.