We now expose idiomatic setters for these properties. Eventually we'll remove
the setter functions.

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.

We still need to tune the various parameters, but this patch is a start.

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 introduces the notion of event disposition and allows event
targets (widgets and render objects) to consume events that should not
be processed further. This is needed by the Switch component in the
Drawer in the stocks example. The Switch is embedded in a DrawerItem.
The Switch handles the gesture tap event to toggle its state and should
handle pointer events to allow swiping and draw its own radial
reaction. The DrawerItem also handles gesture taps to allow toggling
the switch value when tapping anywhere on the drawer and to draw its
own ink splash. When tapping on the switch, both the switch's render
object and the DrawerItem's listener are in the event dispatch path.
The Switch needs to signal in some fashion that it consumed the event
so the DrawerItem does not also try to toggle the switch's state.

This changes Switch from being a subclass of the Toggleable widget to
being a standalone Component with a custom RenderObject. This is to
enable adding Switch-specific radial reaction animations in a
subsequent patch. The CustomPaint logic that Toggleable was using does
not provide a nice way for a class and its subclass to both participate
in deciding to repaint.

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.