Fixes #1381

This patch improves the checkbox animation as suggested by the design
team. The color transition now occurs earlier in the animation and there
are fewer components to the animation.

Fixes #1614

Each layer is supposed to reexport the parts of the previous layer
that are part of its API.

- In painting.dart, export from dart:ui all the Canvas-related APIs
  that make sense to be used at higher levels, e.g. PaintingStyle.

- Delete painting/shadows.dart. It was dead code.

- In rendering/object.dart, export all of painting.dart.

- In widgets/basic.dart, export all of painting.dart and
  animation.dart. Some classes in animation/ are renamed to make this
  less disruptive and confusing to the namespace.

- Split out Stocks back into an import model rather than a part model,
  so that it's easier to manage its dependencies on a per-file basis.

- Move Ticker to scheduler library.

- Remove as many redundant imports as possible now.

- Some minor nit picking cleanup in various files.

We might want to let folks customize the inactive color too, but customizing
the active color is a good place to start.

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

Also, refactor more common code into RenderToggleable and handle dark themes
more correctly.

Fixes #601

 - These controls now have proper radial reactions.
 - You can drag the switch.
 - The radio button animates properly.
 - There's a demo in the Material Gallery

Fixes #219

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.

Make Radio widgets take a type that describes the type of their value,
so that you can catch when you use the wrong value.

Standardise on ValueChanged<Foo> instead of having a FooValueChanged
for every value of Foo.

This makes skyanalyzer also check the examples, and fixes everything it
found there.

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

Fixes #1638

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.

Make checkbox widget to fit more closely to  material design standard. Make changes to remove animation artefacts.

Fixes #1372

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.

The name `root` is confusing because this value isn't the root of anything.
It's just the associated `RenderObject` instance.

We'll need this for compositing because we need to switch out the sky.Canvas
when we switch compositing layers.

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

This refactors Checkbox to own a RenderObject similar to how Switch was
refactored in https://github.com/domokit/sky_engine/pull/376 and
extracts common functionality for toggleable renderers into a base
class.  Switch and Checkbox's render objects derive from this base
class to add their own custom painting and theming logic.

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.