These are now part of material.dart.

Also, have dialog buttons use the accent colour.
Also, generally rationalise some of this stuff to match Material better.

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

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

Fixes #267

(These are changes cherry-picked from in-flight branches since they are
more independent and could be helpful even without those changes.)

- Change RouteBuilder's signature to take a single argument in which the
  other fields are placed, so that we can keep iterating on those
  arguments without having to break compatibility each time. Also, this
  makes defining route builders much simpler (only one argument to
  ignore rather than a variable number).

- Expose the next performance to RouteBuilders, since sometimes the
  route itself might not be where it's used.

- Allow BuildContext to be used to walk children, just like it can for
  ancestors

- Allow BuildContext to be used to get the Widget of the current
  BuildContext

- Allow StatefulComponentElement to be referenced with a type
  specialisation so that you don't have to cast when you know what the
  type you're dealing with actually is.

Fixes #1170

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

Fixes #1372

- Rename EdgeDims constructor to EdgeDims.TRBL().

- Add operator== to Size and Offset so that you can compare Size to
  DebugSize in checked mode.

- Add Size.lerp().

- Add various operators to EdgeDims. (*, /, ~/, %)

- Add EdgeDims.lerp().

- Update style guide. I went there to fix an EdgeDims constructor
  example, and stayed because some recent things came up and I wanted to
  add them before I forgot.

This is step 1 in making it possible to have hero transitions between
routes. To make it possible for a route to have an "exit" animation when
a new route has been pushed on top of it, we provide the next route's
AnimationPerformance to the build function. It's null if there is no
next route or if the next route has no performance.

Instead of having to manage the popup menu from your app's build
function, you now just call showPopupMenu() with the menu's position and
it takes care of everything for you.

This solves the problem that the popup menu was trying to mutate the
state of the navigator from within its own initState() function.

Also, remove the "route" argument to RouteBase.build() since it equals
"this" by definition...

Also, remove ModalOverlay, and instead put that logic in the navigator.

- Fix AnimationTiming to have defaults for 'interval' and 'curve' since
  that seems to be how we use it.

- Merge RouteBase.build and RouteBase.buildTransition

- Get rid of HistoryEntry, since it added nothing

- Broke out RouteBase.createPerformance() so subclasses can change what
  is created.

- Build the routes backwards so that we more efficiently avoid building
  hidden routes.

- Introduce an explicit way (!hasContent) for RouteState to avoid
  building, rather than the implicit "build returns null" we had before.

This fixes #1103.

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.

Almost done adding dartdoc to the rendering layer.

Move the animation libraries into src/animation and change importers to use
package:sky/animation.dart. Also, move scheduler.dart into the animation
library so that the animation library can be self-contained.

This patch makes Center and Align expand by default, which is usually what you
want. It also adds a ShrinkWrap option to let you shrink wrap in one or both
directions if that's really what you want to do.

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.

Add a way of having keys based on numeric types or DateTimes by having a ValueKey<T> class.
Remove the redundant ways of declaring things, except for leaving one shorthand -- you can say `new Key(s)` instead of `new ValueKey<String>(s)`.

Stop exporting framework.dart from basic.dart, since we now have widgets.dart exporting all of framework.dart.

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

Also, add an example for the date picker

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

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

We ended up with a bunch of different scrollable widgets and it was confusing.
This CL moves them all into one library to make them easier to find.

Scoped focus, so you can have a dialog with input controls and not lose your focus in the background.

This introduces a GlobalKey registry so that you can tell when a key
has gone away (so you can unfocus dead dialogs).

Also I added an assert that you're not calling setState() during a
build. It turns out that doing so means you have a bug, because since
you're dirty already (you're building), you won't get rebuilt.

The focus code itself is gnarly. It uses a Component and an internal
Inherited TagNode to manage the focus state, and does crazy things
like updating its state during build to pretend retroactively that it
was built with some other state, once someone asks for focus the first
time (i.e. the first time it's examined, so you can't tell that it was
in a different state before). It does this so that it can autofocus
controls which otherwise wouldn't be focused.

This moves all the focus management into Navigator and showDialog(),
so the complexity is all buried deep and not visible to apps,
hopefully.

To do something like two tabs that each have an Input widget that
needs to be focused when you switch panes, you'd need to have two
Focus objects, one in each tab, and you need to set their autofocus to
true (maybe that should be the default?).

@abarth doesn't like Futures that explicitly point out they're type-unsafe. :-P

This removes the need to manually include the dialog builder in the main window's build() function.
It also removes the need to track if a dialog is visible.

Other changes:
- I made dialog.dart a bit more readable.
- I renamed transitionFinished to fullyOpaque since that's what actually matters.
- I made Routes track if they're opaque. Eventually this should probably be more configurable when creating the route.

Directions for Future Research:
- Use this for focus management somehow.
- The popup menu should use something like this.
- We should factor the following out into a showDialog() function that returns a future for the dialog's exit result:
    navigator.push(new DialogRoute(builder: (navigator, route) { ... }));
- Maybe navigator.pop() should take a value to return to that Future.

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.