This argument isn't needed anymore now that State has a getter for context.

EditableText is now rendered using a custom RenderObject
(RenderEditableParagraph).  RenderEditableParagraph draws the cursor,
handles scroll offsets, and provides feedback about the size of the text for
use by the scroll behavior.

This updates to mojo 4e4d51ce28a and mojo sdk 711a0bcfb141b4 and updates the sky
package's pubspec.yaml dependency to '>=0.1.0 <0.2.0' to be compatible with
the current mojo package. This includes an update to the Mojo Dart generator to
produce real classes for enums and the corresponding updates for users of the
KeyboardType enum in Sky as well as one scoped_ptr->std::unique_ptr in shell
corresponding to a change in the Mojo EDK.

When a new version of the sky and sky_services package are pushed this will fix
domokit/mojo#440.

All the use cases for EventDisposition are now addressed by the gesture
detection system.

What's important about this code is that it's presenting services outside the
VM, not the particular technology used to present the services.

The editing directory just defined two widgets. We might as well fold them into
the main widgets library.

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)`.

For great constness.

Fixes #693

Unforutnately since Input won't show text if it doesn't start
with a letter, this actually makes the experiance slightly
worse, but this is definitely the right direction.

@abarth

@abarth

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.

Assert that there are no duplicates.
Export GlobalKey from basic.dart, so that people don't have to import widgets.dart just for that.
Fix the "initialFocus" feature which actually didn't work.

This patch provides a class to manage focus, Focus, and a class to
manage ownership of the keyboard, KeyboardHandle.

Inherited (in widgets.dart) is adjusted to support subclasses that
need to copy state from instance to instance.

A GlobalKey key type is introduced that is basically the same as
UniqueKey. Component classes that need a globally-unique key can
specify that their 'key' constructor argument is a GlobalKey.

Focus
-----

You can use `Focus.at(this)` to determine if you, a Component, are
currently focused.

You can use `Focus.moveTo(this)` to take the focus or give it to a
particular component.

For this to work, there has to be a Focus class in the widget
hierarchy.

Currently, there can only be one Focus class, because nested scopes
aren't supported. We should add support for that in a future patch.
See issue #229.

KeyboardHandle
--------------

Instead of directly interacting with the keyboard service, you now ask
for a KeyboardHandle using `_keyboard.show(client)`. This returns a
KeyboardHandle class. On that class, you can call `handle.release()`
when you want to hide the keyboard. If `handle.attached` is still
true, and you need to reshow the keyboard after the user hid it, then
you can can `handle.showByRequest()`.

The point of this is that the `keyboard.show()` method maintains the
invariant that only one KeyboardHandle is live at a time.

There are some issues with the keyboard service that I filed as a
result of doing this patch: #226 #227

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.