The problem was we were using a tap gesture to stop the motion of the
drawer and a drag gesture to settle it. That can cause a broken
lifecycle. Now we use a single drag recognizer to drive the whole
lifecycle.

Fixes #775
Fixes #1276

Also, change the keys to be explicitly pointer ids.

Fixes #202

Well, all the easy ones, anyway.

For some reason `// ignore:` isn't working for me so I've disabled
lints that need that. Also disabled those that require a ton of work
(which I'm doing, but not in this PR, to keep it reviewable).

This adds:
- avoid_init_to_null
- library_names
- package_api_docs
- package_names
- package_prefixed_library_names
- prefer_is_not_empty
- sort_constructors_first
- sort_unnamed_constructors_first
- unnecessary_getters_setters

There's no reason to make clients supply a PointerRounter and a
GestureArena when constructing gesture recognizers. These objects are
statics and the gesture recognizers can just grab them directly.

Also, remove the callback constructor arguments. Almost no code used
them. Instead, people seem to prefer using the `..` operator to set
callbacks on the recognizers. Removing the arguments removes a bunch of
boilerplate.

This allows us to adjust exactly which gestures we're listening for
during layout, which I'll use to kill a SizeObserver.

#1968

Previously we asserted that we got a pointer move to the location where the
pointer up occured, but not all sources of pointer packets respect that
invariant. Specifically, on the iOS simulator, of you drag outside the window,
you'll get a stream of pointers that violates that invariant.

This patch teaches the converter to insert a PointerMoveEvent to move the
pointer to the location where the up occurs, repairing the invariant.

Fixes #1912

We were using an Offset, which represented pixels/second, but it wasn't
clear to clients whether that was pixels/ms. Now we use a Velocity class
that is explict about the units.

Fixes #1510
Fixes #785

...even after winning the arena.

This lets it cooperate with other gestures like tap.

The way I implemented this was to refactor the entire Draggable gesture
logic to use a new kind of gesture detector called
MultiDragGestureRecognizer. It works a bit like
MultiTapGestureRecognizer but for drags.

Also some tweaks to the velocity estimator.

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.

The dart bindings changed semantics in a non-compatible way.

The pointer router was using an iteration pattern that always delivers
handleEvent calls even if you remove a route during the iteration.
That's awkward to program against and causes trouble for the double-tap
gesture.

This patch switches PointerRouter to using a re-entrant iteration
pattern that supports removing routes (but not adding routes) during the
iteration.

- make them all have the same style
- make them all include the stack trace last
- make them all stop printing if their callback is set (if
  appropriate, they don't yet all have callbacks)

If we don't catch these exceptions, we get confused about what's going
on with the pointers, and the app basically stops working.

Instead of PointerInputEvent having a "type" field, we now have a
different class for each pointer type.

This has ripple effects throughout the system.

I also did code cleanup in affected files while I was there.

To make the units clear.

Make sure to send tapcancel when the primary pointer fails because of
slop, even if the gesture won by default.

Also, minor cleanup and clarification of an invariant.

Draggable is now itself a gesture arena member. This means it won't
conflict with other gesture recognisers in the same path.

This also allows variants of Draggable that are triggered by other
gestures.

Also, some cleanup of DoubleTapGestureRecognizer, GestureDetector, and
PrimaryPointerGestureRecognizer.

Also, make MultiTapGestureRecognizer support a timeout for longpress.

Also, make Draggable data be typed.

Also, hide warnings about constructor warnings for now. Analyzer doesn't
support them yet. (Have to do this on a per-line basis)

Directions for future research:
 - animating the avatar (enter/exit transitions)
 - interaction with the navigator (canceling a drag on page navigation, etc)
 - double-tap draggable

Make all the *GestureRecognizer classes inherit from a class called
GestureRecognizer. Give the old GestureRecognizer a name that is more
precise about its purpose. Remove the members of GestureArenaMember that
aren't used by GestureArenas.

Document the Gesture Detector constants.

Remove kEdgeSlop since it's obsolete on Android.

Add a test that verifies that when the first tap is canceled, the second
tap can become the first tap of a subsequent two-tap sequence.

Tap and the othes classes in tap.dart are not really related.

Turns out there were no uses of GestureArenaMember other than those that
use DisposableArenaMember.