Changed drawer header to use theme's divider color.

Instead of a PNG, the Flutter gallery widget is now drawn in code.

There's now a FlutterLogoDecoration class that paints the flutter logo
anywhere you can use a Decoration (e.g. AnimatedContainer).

There's now a FlutterLogo class that honors the IconTheme.

The About dialog box API now takes a Widget for the applicationIcon,
instead of an ImageProvider. It uses IconTheme to make the icon the
right size instead of using an Image widget.

Add padding, duration, and curve properties to the DrawerHeader.
Make the child of a DrawerHeader optional.

Clean up UserAccuntsDrawerHeader a bit.

Add some useful properties and methods to EdgeInsets.

Add some debug logic to RenderDecoratedBox to catch unpaired
save/restore calls when possible.

Make GestureDetector fill its parent if it has no children. Fixes
https://github.com/flutter/flutter/issues/5380

Removed old Stack layout and added a simple-to-extend interface for the
new drawer header. Also added a specialized UserAccountsDrawerHeader
consistent with Material Design guidelines.

This reverts commit 55f9145e.

Turns out that this commit breaks apps that use the material library,
because of the _errorTextStyle DefaultTextStyle which has inherit:true.
Just setting it to false doesn't work, unfortunately, because then you
hit some sort of issue with merging that text style with others that
have inherit:true.

To make it clear that this constructor requires an explicit style. Also
throw a descriptive error recommending the inherit constructor for
styles with the inherit bit set.

Fixes #3842

The dartdoc will continue until morale improves.

Also, fill out other documentation for these widgets.

Fixes #967

Now MediaQuery.of always returns a non-null value. By default, you get the
values associated with the current ui.Window.

Fixes #2894

This patch adds a consistent, simple description for the common pattern of
having a single child widget.

This patch renames StatelessComponent to StatelessWidget and
StatefulComponent to StatefulWidget.

Fixes #2308

Fixes #1382

Fixes #1278

Previously we used a positional argument for widgets that had multiple
children. Now we use a named argument that defaults to an empty list.

Fixes #241

After this patch, if you try to use a widget that depends on being enclosed in
a material, you now get an assert and a debugPrint if you're not inside a
material.

Fixes #243

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.

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.

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.

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

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

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.