This patch makes the level of the ToolBar configurable. I've also cleaned up
the Tab code slightly.

For some reason, there's still a hairline between the ToolBar and the TabBar.
We might need to rethink how we draw the background a bit here.

Fixes #1454

Now SnackBar is an ephemeral route that uses a Placeholder to put itself into
the Scaffold.

Fixes #673

Fixes #1170

This patch converts drawer to using the "openDialog" pattern for managing its
state. Currently, the drawer entrance and exit animation aren't integrated with
the navigator's animation system because the drawer's animations can be stopped
and reversed, which the navigator can't yet understand. That means dismissing
the drawer via the system back button causes the drawer to be removed
instanteously.

Fixes #715
Fixes #1187

Identify specific parts of a Stock row with a Global Key that can be
regenerated later, and pass that key back to event handlers so they can
use them to do the transition.

Make it possible for named routes to be generated on the fly.

To demonstrate this, you can now long-press a stock to open it.

Next steps:

 - transitions between (named) states that follow full material logic,
   e.g. in the case of the stock row to stock page transition, expanding
   the row into a raised sheet of material and expanding it to fit the
   screen, leaving the toolbar in place but cross-fading the old
   contents to the new contents.

 - more information in the stock view.

While I was here I also made Material have an opinion about default text
style, so if you forget to set one, it just uses body1.

Also, fixed bugs introduced recently that made RouteState and MenuRoute
not work properly.

Not having them clickable was making it hard to notice InkSplash bugs.
Also, this paves the way to having a stock page.

This changes how SnackBar works so you can use it anywhere, not just on
the bottom edge of the screen (it used to rely on overflowing its bounds
and having negative offsets... I'm not really sure how hit testing
worked on it before!).

To do this I introduced a new RenderBox, RenderOverflowBox, that lets
you set your child's size independent of your own. I needed this so that
the snack bar could use a SquashTransition to change its size, while not
affecting the layout of its child. This is exposed as OverflowBox in
fn3. I'm not sure if it's the best API. It doesn't let you position the
child (which is an issue if the size you give is smaller), it doesn't
let you give a loose constraint (which maybe you might want?). But it
handles this use case, so for now it's probably ok.

Making the FAB get repositioned out of the way of the Snack Bar is now
done in the Scaffold, which is in charge of positioning both of those
and is the place that knows that both exist.

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

Instead of having to manage the popup menu from your app's build
function, you now just call showPopupMenu() with the menu's position and
it takes care of everything for you.

This solves the problem that the popup menu was trying to mutate the
state of the navigator from within its own initState() function.

Also, remove the "route" argument to RouteBase.build() since it equals
"this" by definition...

Also, remove ModalOverlay, and instead put that logic in the navigator.

This fixes #1103.

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.

This still leaves Flex and FlexDirection available. At some point once
people have transitioned to Row/Column we should rename Flex to _Flex
and stop reexporting FlexDirection from basic.dart.

Mostly formating and removing arguments with default values.

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 introduces the concept of an Anchor, which you can use to link
transitions together. I've used this in the Fitness and Stocks apps to
link the FAB and SnackBar to animate together by sharing the
SlideTransition.

I also fixed the Scaffold hit testing code to apply sub-widget
transforms, so it works with Transformed nodes.

We only use them for the transition to dismissed.

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.

SnackBar, and PopupMenu instead of custom statuses.

Scoped focus, so you can have a dialog with input controls and not lose your focus in the background.

This introduces a GlobalKey registry so that you can tell when a key
has gone away (so you can unfocus dead dialogs).

Also I added an assert that you're not calling setState() during a
build. It turns out that doing so means you have a bug, because since
you're dirty already (you're building), you won't get rebuilt.

The focus code itself is gnarly. It uses a Component and an internal
Inherited TagNode to manage the focus state, and does crazy things
like updating its state during build to pretend retroactively that it
was built with some other state, once someone asks for focus the first
time (i.e. the first time it's examined, so you can't tell that it was
in a different state before). It does this so that it can autofocus
controls which otherwise wouldn't be focused.

This moves all the focus management into Navigator and showDialog(),
so the complexity is all buried deep and not visible to apps,
hopefully.

To do something like two tabs that each have an Input widget that
needs to be focused when you switch panes, you'd need to have two
Focus objects, one in each tab, and you need to set their autofocus to
true (maybe that should be the default?).

Converted demo launcher example to library

Converted fitness example to library

Converted hello world example to library

Converted mine digger example to library

Converted stocks example to library

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

Route (named routes) no longer have a key, and have their own storage for their names.
RouseState no longer has a key, and uses an owner field pointing to a StatefulComponent instead.
As such, RouteBase no longer has a key.

HistoryEntry no longer uses a global int to ensure uniqueness.

Propagated this to stocks app.