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.