We now have separate gestures for horizontal, vertical, and pan scrolling.

Instead, we pump a onScrollUpdate with the offset if there is an offset.

This patch replaces the scroll gestures used by Scrollable with ones detected
by the ScrollGestureDetector.

These gestures use the new gesture detection system.

Also includes changes to widget_tester sufficient to
test scrolling.

@abarth

Added Scrollable named parameter initializeScrollOffset. If unspecified, then the initial value of scrollOffset is 0.0 as before.

If there aren't any items, there's no point in computing which items to show.

We now compute which items to show using integers instead of floating point,
avoiding rounding errors.

Adds itemsWrap:bool (default false) to ScrollableList and PageableList. If itemsWrap is true then scrolling past the last item wraps around to the first. Similarly, scrolling before the first item wraps around to the last.

Added abstract ExtentScrollBehavior of ScrollBehavior. Renamed fields called contentsExtents to contentExtent, containerExtents to containerExtent, contentSize to contentExtent, etc.

BoundedBehavior is now a subclass of ExtentScrollBehavior.

Added UnboundedBehavior subclass of ExtentScrollBehvaior; contentExtent and maxScrollOffset are double.INFINITY, minScrollExtent is double.NEGATIVE_INFINITY.

 - Introduce _setScrollOffset as a backend for the animations so that scrollTo
   can stop animations.

 - Create a single function that stops both kinds of scroll animations.

 - Refactor how we update the bounds for bounded scroll behaviors so that we
   update the bounds and compute the new scroll offset at the same time.

Block -> BlockBody
ScrollableBlock -> Block
FixedHeightScrollable -> ScrollableWidgetList
VariableHeightScrollable -> ScrollableMixedWidgetList
BlockViewport -> MixedViewport

Changed the pageable_list.dart example: tapping on the toolbar changes
the scroll direction. This exposed some problems:

- Scrollable.syncFields() didn't update scrollDirection
- Viewport updated its RenderObject fields in the wrong order
- FixedHeightScrollable scrollDirection changes didn't update the scrollBehavior

There may be similar problems with VariableHeightList and ScrollableViewport.
I will fix those in a separate CL.

Rather than using a Padding widget to provide padding along the scrolling axis,
we now just figure the padding into where we draw the items. This patch fixes
an issue where we would remove the first topmost item in a scrollable list too
early because we thought it was already off screen.

Fixes #697

Fixes the Stocks crash on startup.

Fixes tests.

- PageableList extends ScrollableList
One fixed width or height item is visible and centered at a
time. Fling and drag gestures scroll to the next/previous item.

- Scrollable.scrollTo(), Scrollable.scrollBy(), ensureWidgetIsVisible() API changed
The named animation parameter for these methods was replaced by
duration and curve. All of the methods now return a Future. The Future
completes when the scroll does.

This change eliminates the need for Scrollable to temporarily take ownership
of a ValueAnimation object (see #645).

- Using Future.then() instead of an AnimationPerformance status listener
In ensure_visible.dart _handleTap() uses ensureWidgetIsVisible() to
center the card roughly as before and then. When the implicit scroll
animation is complete, it changes the centered card's label font. The
change is made when the Future returned by ensureWidgetIsVisible()
completes.

- FixedHeightScrollable's itemHeight parameter is now itemExtent
If scrollDirection is ScrollDirection.vertical (the default) then itemExtent should
be the height of each item; otherwise it should be the width of each item.

Replaced _velocityForFlingGesture() in scrollable.dart with Scrollable._eventVelocity()
The original version clamped pixels/ms against pixels/sec constants. The new version
also deals with scrollDirection.

- Plumbed scrollDirection though FixedHeightScrollable and ScrollableList

Both classes should now support horizontal scrolling.

Sadly, box.dart has grown much longer than 1000 lines. This patch splits it up
into several files based on the class hierarchy. Fortunately, many of these
classes are loosely coupled to each other.

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

Used for AnimationPerformance with a single AnimatedValue<T> variable.

Set the scrollOffset of a widget's Scrollable ancestor so that the
widget is centered within the scrollable. A future CL will add
support for specifying exactly where the widget appears. The scroll
can be animated by specifying the animation: parameter.

Changed the duration Scrollable.scrollTo() parameter from a Duration
to an AnimationPerformance so that one can configure all aspects of
the animation. The caller may also listen to the animation to schedule
other work while it updates or when its status changes.
complete

The IgnorePointer class enables one to cut a widget subtree off from pointer events. This is useful when a sibling should not shield pointer events from overlapping siblings below it.

Added a ScrollListener listener to Scrollable. The ScrollListener runs each time the Scrollable's scrollOffset changes. This can be used to keep overlay widgets in sync with a Scrollable below them.

Removed the Scrollable ScrollClient API. It was no longer used and was clumsy to use as a ScrollListener.

Added global function findScrollableAncestor() to scrollable.dart.

Added examples/widgets/overlay_geometry.dart. The app's Scaffold is contained by a Stack. The Stack is used to display green overlay "Markers" at the corners of the most recently selected list item and where the corresponding tap occurred. The app uses widget.localToGlobal() to compute the global overlay positions of the markers. The ScrollListener is used to keep the markers' positions up to date.

Now ScrollableBlock can combine a horizontally scrolling viewport with a
horizontal block.

Also rename ViewportScrollDirection to just ScrollDirection for less verbosity.

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

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.

When a ScrollableBlock can scroll, we want to be able to drag into the
overscroll region. Previously we could fling into the overscroll region, but we
couldn't actually drag there.

We ended up with a bunch of different scrollable widgets and it was confusing.
This CL moves them all into one library to make them easier to find.

When the selected tab changes in a TabBar for which isScrollable:true, animate the selected tab to the center of the viewport, if that's possible.

Added an optional duration: to Scrollable.scrollTo(newOffset, duration: d) which animates the scroll to newOffset.

Refactored the Scrollable implementation a little to make the roles of the "toEnd" and "toOffset" animations clearer.

_handlePointerDown() now stops both animations.

Similarly, we only call settleScrollOffset() from the cancel gesture handlers if the animations aren't already running.

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.