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.

Instead of requiring clients to use ui.ColorFilter, we show show the
ColorFilter class, similar to what we do for Color.

The goal is to follow the guidelines in
https://github.com/flutter/engine/blob/master/sky/specs/style-guide.md#packages

Fixes #1638

These are now part of material.dart.

Clients should just use a GestureDetector (or an InkWell) instead.

Now we trigger the highlight from the InkWell so that it matches the tap.

Fixes #1525

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

Fixes #267

After this patch, InkWell is driven by gesture recognizers, which lets us
cleanly cancel splashes when the user actually scrolls.

I've also refactored all the clients of InkWell to use InkWell to detect
gestures instead of wrapping InkWell in a GestureDetector.

Fixes #1271

 * Rename GestureTapListener (and friends) To GestureTapCallback to match the
   other gesture callbacks.
 * Replace "ensureFoo" pattern with ??= operator.

Also, introduce Colors and Typography to hold the material colors and the
typography declarations. Previously we expected clients of these libraries to
import them into a namespace, but that doesn't play nice with re-exporting them
from material.dart.

Everyone uses sky.view.scene now. This patch also cleans up the raw examples
and makes them follow a consistent pattern.

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.

We're now using it at the widget layer for everything except scrolling and
flinging.

I updated everything in widgets/, but didn't update any examples.

These widgets were designed in CSS where you need to specify a layout model for
your children. This patch updates them to the modern style of just taking a
unique child.

Fixes #755

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

This introduces the notion of event disposition and allows event
targets (widgets and render objects) to consume events that should not
be processed further. This is needed by the Switch component in the
Drawer in the stocks example. The Switch is embedded in a DrawerItem.
The Switch handles the gesture tap event to toggle its state and should
handle pointer events to allow swiping and draw its own radial
reaction. The DrawerItem also handles gesture taps to allow toggling
the switch value when tapping anywhere on the drawer and to draw its
own ink splash. When tapping on the switch, both the switch's render
object and the DrawerItem's listener are in the event dispatch path.
The Switch needs to signal in some fashion that it consumed the event
so the DrawerItem does not also try to toggle the switch's state.

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.