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.