Also:
 - add operator==/hashCode/toString to ViewportDimensions
 - add toString to BindingBase
 - add toString and debugFillDescription to ScrollBehavior
 - fix a bug in the RawGestureDetectorState's replaceGestureRecognizers
 - rename MixedViewport's onExtentsUpdate to onExtentChanged
 - replace ExtentsUpdateCallback with ValueChanged<double>
 - remove a microtask for dispatching scroll start, since it
   did not appear to have any purpose
 - added dartdocs to Instrumentation until I understood it
 - made all event dispatch in Instrumentation drain microtasks

This patch fixes a couple minor bugs and cleans up MixedViewport a bit.

* Use actual exceptions rather than assertions containing code
  containing strings when trying to give messages to authors.
* Introduce RenderingError which is an AssertionError that takes a
  string argument, to support the above.
* Provide a BoxDimensions.hasBoundedWidth/hasBoundedHeight API.
* Document BoxDimensions.isNormalized.
* Provide more useful information when we assert isNormalized and find
  that it is false.
* When finding the size is infinite, crawl the tree to figure out which
  render box is likely responsible for the infinite constraints.
* Provide more information when size doesn't match the constraints.
* Provide more information when intrinsic dimension methods violate the
  constraints.
* Only spam a huge amount of information for the first exception from
  the rendering library. I've noticed a lot of people looking at the
  last exception printed rather than the first and that's very
  misleading -- after the rendering library hits an exception, all bets
  are off regarding what'll happen in the future. All kinds of asserts
  might fire.
* Improve docs around the debug methods and flags for the above.
* Make Block default to have no children. Previously, giving no children
  crashed with a confusing message about a null deref in an assert.

This patch changes the framework to walk the child list forwards so that build
functions with global side effects do sensible things. Specifically, if you
have a number of autofocusable children, the first one the list will acquire
the focus because it gets built first now.

Fixes #182

RenderBlock wasn't constraining the results.
RenderPadding wasn't constraining the results (which matters
especially when the constraints can't fit the padding in the first
place).
RenderViewport wasn't constraining the results.

Add a test for the block case.

To catch this kind of thing in the future, add some asserts to
debugDoesMeetConstraints() that all four intrinsic functions return
values that are within the constraints.

RenderBlockViewport doesn't support returning intrinsics, so turn off
the "no intrinsic support" asserts (and return zero) when we're doing
this new assert.

This new assert screwed up the custom layout classes' tests, so adjust
those tests to ignore the callbacks invoked from these asserts.

Add to the _debugReportException() method a short summary of the
descendants of this node. It's important to have this information when
debugging errors like these intrinsic constraints contract violations
because often nodes just pass the values through to their child so you
have to go several steps down to find the actual problem.

Fixes https://github.com/flutter/flutter/issues/1210

We use the ScrollDirection for more than just scrolling.

Fixes #151

We'll probably renaming ScrollDirection to Axis in a future patch.

Fixes #151

Almost none of the clients of ScrollDirection can handle scrolling in both
directions.

Fixes #151

MixedViewport didn't use the building:true flag when locking itself, so
when it caused a rebuild of its children, we assumed that nobody was
allowed to mark things dirty below the list, and things crashed when
Inherited people did in fact rebuild.

Also:
 - default offset for MixedViewport
 - don't bother rebuilding if the underlying RenderObject is going to
   rebuild anyway for some reason
 - better docs for the "items must have keys" assert
 - keep the FlipComponent stuff together in test_widgets.dart

- Change RouteArguments to pass the route's BuildContext rather than
  the Navigator. This caused the bulk of the examples/ and .../test/
  changes (those are mostly mechanical changes). It also meant I could
  simplify Navigator.of().

- Make initState() actually get called when the State's Element is in
  the tree, so you can use Foo.of() functions there. Added a test for
  this also.

- Provide a RouteWidget so that routes have a position in the Widget
  tree. The bulk of the route logic is still in a longer-lived Route
  object for now.

- Make Route.setState() only rebuild the actual route, not the whole
  navigator.

- Provided a Route.of().

- Provided a Route.writeState / Route.readState API that tries to
  identify the clients by their runtimeType, their key, and their
  ancestors keys, up to the nearest ancestor with a GlobalKey.

- Made scrollables hook into this API to track state. Added a test to
  make sure this works.

- Fix the debug output of GestureDetector and the hashCode of
  MixedViewport.

- Fixed ScrollableWidgetListState<T> to handle infinite lists.

(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.

These are now part of material.dart.

Previously, RenderObjectElements didn't support being marked dirty. This
is fine, except for MixedViewport and HomogeneousViewport, which have
builder functions to which they hand themselves as a BuildContext. If
those builder functions call, e.g., Theme.of(), then when the theme
changes, the Inherited logic tries to tell the RenderObjectElement
object that its dependencies changed and that doesn't go down well.

This patch fixes this by making RenderObjectElement a BuildableElement,
and making MixedViewport and HomogeneousViewport hook into that to
rebuild themselves appropriately.

Also, this was only found at all because ThemeData didn't implement
operator==, so we were aggressively marking the entire tree dirty all
the time. That's fixed here too.

Also, I changed card_collection.dart to have more features to make this
easier to test. This found bugs #1524, #1522, #1528, #1529, #1530, #1531.

In the vast majority of cases, folks should be interacting with the Widget
rather than its State.

Fixes #267

Fixes #1372

This removes GlobalKey.currentElement in favour of GlobalKey.currentContext.

If it's a StatefulComponent, then it's ok to reuse it so long as it
hasn't been initialised.

If it's a regular Component or a TagNode, then it's always ok to reuse.

If it's a RenderObjectWrapper, then it's ok to reuse so long as it
doesn't have a renderObject.

To put it another way, this changes how we prevent the following
nonsensical situations from arising:

 - Sync two stateful StatefulComponents together
 - Sync two RenderObjectWrappers with RenderObjects together

When either of those cases happen, we just drop the old one on the
ground and use the new one unchanged.

Code outside of package:sky should import this code using

package:sky/rendering.dart
package:sky/widgets.dart

Moving this code into the "src" directory is a convention that signifies that
and it cleans up the generated dartdoc because the libraries in the src
directory aren't included in the generated documentation. Instead, the classes
are documented in the widgets.dart and rendering.dart libraries.

Adds a HomogeneousViewport class that works like MixedViewport but
handles only children that have all the same height.

Converts ScrollableWidgetList to use that, so that we don't waste a
frame looking at the size of the contents each time we change size.

This allows a number of seemingly pointless double-pumps in the tests
to be removed.

Other changes that were necessary to support the above:

 - RenderBlock now supports minExtent (think 'min-height' in CSS)
 - RenderBlock now supports itemExtent (forces the height of each
   child to be the same, so that the itemExtent passed to the fixed-
   height scrollables are all authoritative instead of a source of
   bugs when they don't match)
 - RenderBlockViewport now supports horizontal scrolling
 - improved the style of the isInfinite assert in box.dart
 - fixed the position of a comment in mixed_viewport.dart
 - added a test
 - made the logic for how many items to show be more precise

We need to always remove the widget when you sync a non-visible
widget, even if we already have it, because otherwise we'll try to
sync it with null again later, which causes a crash.

Test in #938.

...and not when we mount and dismount.

Turns out that when we dismount, it's too late -- we've already set
renderObject to null.

We also mark the mixed viewport as dirty when it is removed from its parent.
Without this, we try to reuse the child nodes in subsequent syncs, which is a disaster.

Generalise RenderBlockViewport so that it can be used by a Widget that knows its children's dimensions.

Block -> BlockBody
ScrollableBlock -> Block
FixedHeightScrollable -> ScrollableWidgetList
VariableHeightScrollable -> ScrollableMixedWidgetList
BlockViewport -> MixedViewport

This function just calls remove(). Also, have Widget do the recursive remove
walk by calling walkChildren.

We now use the term `renderObject`.

Fixes #708

The name `root` is confusing because this value isn't the root of anything.
It's just the associated `RenderObject` instance.

It was confusing to have both widget.dart and widgets.dart

This fixes some theoretical bugs whereby we were using hashCode to try
to get unique keys for objects, but really we wanted object identity.
It also lays the groundwork for a new GlobalKey concept.

I tried to keep the impact on the code minimal, which is why the "Key"
constructor is actually a factory that returns a StringKey. The code
has this class hierarchy:

```
   KeyBase
    |
   Key--------------+---------------+
    |               |               |
   StringKey    ObjectKey       UniqueKey
```

...where the constructors are Key and Key.stringify (StringKey),
Key.fromObjectIdentity (ObjectKey), and Key.unique (UniqueKey).

We could instead of factory methods use regular constructors with the
following hierarchy:

```
   KeyBase
    |
   LocalKey---------+---------------+
    |               |               |
   Key      ObjectIdentityKey   UniqueKey
```

...with constructors Key, Key.stringify, ObjectIdentityKey, and
UniqueKey, but I felt that that was maybe a more confusing hierarchy.
I don't have a strong opinion on this.