* Manually fix every use of Point.x and Point.y

Some of these were moved to dx/dy, but not all.

* Manually convert uses of the old gradient API

* Remove old reference to Point.

* Mechanical changes

I applied the following at the root of the Flutter repository:

git ls-files -z | xargs -0 sed -i 's/\bPoint[.]origin\b/Offset.zero/g'
git ls-files -z | xargs -0 sed -i 's/\bPoint[.]lerp\b/Offset.lerp/g'
git ls-files -z | xargs -0 sed -i 's/\bnew Point\b/new Offset/g'
git ls-files -z | xargs -0 sed -i 's/\bconst Point\b/const Offset/g'
git ls-files -z | xargs -0 sed -i 's/\bstatic Point /static Offset /g'
git ls-files -z | xargs -0 sed -i 's/\bfinal Point /final Offset /g'
git ls-files -z | xargs -0 sed -i 's/^\( *\)Point /\1Offset /g'
git ls-files -z | xargs -0 sed -i 's/ui[.]Point\b/ui.Offset/g'
git ls-files -z | xargs -0 sed -i 's/(Point\b/(Offset/g'
git ls-files -z | xargs -0 sed -i 's/\([[{,]\) Point\b/\1 Offset/g'
git ls-files -z | xargs -0 sed -i 's/@required Point\b/@required Offset/g'
git ls-files -z | xargs -0 sed -i 's/<Point>/<Offset>/g'
git ls-files -z | xargs -0 sed -i 's/[.]toOffset()//g'
git ls-files -z | xargs -0 sed -i 's/[.]toPoint()//g'
git ls-files -z | xargs -0 sed -i 's/\bshow Point, /show /g'
git ls-files -z | xargs -0 sed -i 's/\bshow Point;/show Offset;/g'

* Mechanical changes - dartdocs

I applied the following at the root of the Flutter repository:

git ls-files -z | xargs -0 sed -i 's/\ba \[Point\]/an [Offset]/g'
git ls-files -z | xargs -0 sed -i 's/\[Point\]/[Offset]/g'

* Further improvements and a test

* Fix minor errors from rebasing...

* Roll engine

Covers lib/ in package:flutter.

Previously, the Slider used a drag gesture recognizer to move the head
of the slider, but when the slider was in a vertical scroller, the
recognizer would wait until the user moved the pointer by enough pixels
to disambiguate between sliding the slider and scrolling the scroller.

That worked fine for actual drags, but the slider should also move when
the user taps the track. This patch introduces a tap recognizer to
handle that behavior.

To avoid the slider's drag and tap recognizers from competing with each
other in the arena, this patch introduces the notion of a
GestureArenaTeam, which lets several recognizers combine to form one
entry in the arena.  If that entry wins, the team picks the first of its
recognizers as the winner, avoiding latency.

Fixes #7454

- more dartdocs for the drag typedefs

- more toStrings to aid debugging

- require the position for DragUpdateDetails since we were omitting it
  in some places

- add the primaryVelocity to DragEndDetails so that consumers don't
  have to themselves track the axis in question

- fix the velocity tracker so that it doesn't walk the null data.
  Previously, near time t=0 (which pretty much only matters in tests,
  but it does matter there) we would walk the velocity data and then
  also walk missing data, treating it as Point.zero with t=0.

- simplify some of the velocity tracker; e.g. instead of trying (and
  failing?) to clear the velocity tracker when the pointer stalls,
  just drop the data before a stall during the velocity estimation
  (where we redundantly had another bigger horizon anyway).

If a recognizer is interrupted by an exception from a callback, it could be
left in an inconsistent state and be unable to process future events

Previously, we were nulling out the ArenaEntry in MultiDragPointerState
too early, which was prevent MultiDragPointerState from rejecting the
gesture in `dispose` if we hadn't accepted by the time the pointer went
up. Now we properly reject the gesture, which causes the tap gesture to
win during `sweep` in the arena.

Also, add a bunch of docs and annotations based on information I learned
while studying this issue. Finally, rename a private member of tap
recognizer to a name that would have confused me less in my
investigation.

Fixes #1186

Fixes #4761

We were trying to unregister the pointer route twice. Now we only unregister it
once.

Fixes #4341

This patch starts using the mustCallSuper annotation for several of the key
lifecycle callbacks in the framework. I haven't added it to didUpdateConfig
because there are a large number of non-compliant overrides. We should discuss
whether we want to use it there.

Also, make some previously private classes public for better
documentation.

Wait until the end of the microtask to tell gesture recognizers that
they've won in the gesture arena. This lets recognizers dispose reject
themselves at arbitrary times without triggering gestures in awkward
call stacks.

Fixes #3183

The old names were getting silly and started stepping on valuable namespace.

The new names are consistent and clear.

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

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.

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.

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.

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.

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

Add type annotations in many places.
Fix some identifiers to have more lint-satisfying names.
Make all operator==s consistent in style.
Reorder some functions for consistency.
Make ParentData no longer dynamic, and fix all the code around that.

Now that you import a top-level file for each layer of the Flutter
framework, within the framework we can use relative paths without being
worried about the copy/pasta problem we used to have.

Fixes #1320

This patch is part of a sequence of patches towards fewer top-level libraries.
In this patch, the gesture libraries are combined into one gestures.dart
library.

That way the fling engages in the same direction as the scroll. For example, if
you have a horizontal scroll nested inside a vertical scroll, the fling will
take place in the same direction as the scroll.