We now use the `@required` annotation to encourage developers to
explicitly set onPressed and onChanged callbacks to null when that would
disable the widget.

Fixes #287

Fixes 3544

For consistency.

Fixes #4142

Making progress towards document all public APIs in material.dart. We're still
missing a few odds and ends (as well as missing docs in tabs.dart,
tooltip.dart, and two_level_list.dart).

Instead of incorporating the margin into the button, introduce a ButtonBar
widget that supplies the proper spacing between the buttons. Also, make these
buttons more configurable via ButtonTheme so that dialogs can change the
minWidth and padding of the buttons as required by the spec.

Fixes #1843
Fixes #3184

Also, clean up a few interfaces that looked awkward when writing docs.

Also, fill out other documentation for these widgets.

Fixes #967

These files are already in the "material" folder. They don't need to be
prefixed with material again.

Fixes #702

Fixes https://github.com/flutter/flutter/issues/1331

Hopefully this will be enough to start with. If this continues to be a
point of confusion we can see about adding more documentation or
changing the API somehow.

Shadows now render as three seprate MaskFilter.blur components per the most recent Material spec.

The shadows Map was replaced by a similar Map called elevationToShadow with entries that match the 10 elevations specifed by http://www.google.com/design/spec/what-is-material/elevation-shadows.html.

The "level" property (many classes) is now called "elevation", to match the Material spec.

BoxShadow now includes a spreadRadius parameter - as in CSS box-shadow. Renamed the BoxShadow blur property to blurRadius to further align BoxShadow with CSS box-shadow.

Previous these callbacks were leaking the implementation detail that they were
triggered by taps. In a later patch, we're going to add a parameter to
GestureTapCallback that these callbacks won't have.

Related to #1807

Instread of an explicit 'enabled' bool, this uses the presence of the
event handler to determine if a widget is enabled or not. This means
that if you've not passed a handler, your widget will be disabled, which
makes sense, since it wouldn't work anyway.

Adds this feature to checkbox, and ports raised button, flat button, and
radio buttons to this new model.

Adds a checkbox to card_collection that can be disabled.

Hide a (basically bogus) hint from the (soon to be disabled) strong hint
mode in the analyzer that this reveals.

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.

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

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

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.

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.