Previously, if you changed buttons during a long-press gesture, if it was before the gesture was accepted we would discard it, and if it was after the gesture was accepted we would silently end it without firing any of the relevant events.

This silent cancelation behavior is terrible because it means there's no way for consumers to know what state they're in, so you end up with widgets that thing they're still being long-pressed even though nothing is happening.

We could change the behavior in three ways, as far as I can tell:

- we could send a cancel event when you change buttons. This would introduce a new kind of transition (start->cancel) which I don't think we currently require people to support. This would therefore not fix existing code and would make future code more complicated to handle a really obscure user action that it seems unlikely anyone cares about.

- we could send an end event when you change buttons. This would mean the action commits, even though the user is still holding the mouse button down. This seems slightly better than the previous option but still not ideal as it means nudging the mouse button commits you even though you're still holding the button down.

- we could ignore button changes after the long-press has been accepted.

I implemented the last one in this PR.

Remove 1745 decorative breaks

* Remove deprecated kind in GestureRecognizer et al

* Fix null case

* DragTarget part 1.

[WIP] Change GestureRecognizer. Sorry.

[WIP] Move from GestureRecognizer to MultiDragGestureRecognizer.

Make it a `Set<int>?`

Get bitwise operations working.

Fix test. Rename to allowedInputPointers.

Convert into a builder.

Improve code with default funciton.

Refactor everything again.

Rename to buttonEventFilter.

Use static function.

Fix analyzer.

Fix private reference.

Use // in private method.

* Fix Renzo request.

* Add `allowedButtonsFilter` everywhere.

* Refactor monoDrag for multi pointer support.

* Fix tests?

* Change default to always true.

* Fix PR comments.

* Completely refactor long press.

* Add forgotten class.

* Revert "Completely refactor long press."

This reverts commit 5038e8603e250e8c928b0f1754fb794b7b75738b.

* Add default value to LongPress

* Refactor doubleTap.

* Relax double tap.

* Write comment in LongPress.

* Use template.

Use `curly_braces_in_flow_control_structures` for `foundation`, `gestures`, `painting`, `physics` (#104610)

* Use `curly_braces_in_flow_control_structures` for `foundation`

* Use `curly_braces_in_flow_control_structures` for `gestures`

* Use `curly_braces_in_flow_control_structures` for `painting`

* Use `curly_braces_in_flow_control_structures` for `physics`

* fix comments

* remove trailing space

* fix TODO style

This adds support for GestureDetector.onLongPressDown and
GestureDetector.onLongPressCancel, allowing callers to register
interest in the initial pointer contact that might turn into
a long-press (and the associated cancel event if the gesture
loses).

Deprecate VelocityTracker default constructor and added VelocityTracker.withKind constructor (#66043)

We've gotten feedback that the VelocityTracker change was disruptive, though it did not break any of the flutter framework or customer tests. In order to make the change non-breaking, PointerDeviceKind parameter can be made optional.

Nevertheless, this parameter should be provided so that the existing touch handlers can use more accurate gestures on mouse/stylus inputs, so we can encourage this by deprecating the default constructor and pointing users towards the VelocityTracker.withKind constructor that takes a non-optional parameter

Currently the framework uses fairly large "hit slop" values to disambiguate taps from drags/pans. This makes sense on touch devices where the interaction is not very precise, on mice however it can feel as if the UI is lagging. This is immediately noticeable on our infra dashboard, where it takes almost half of a grid square of drag before the actual drag kicks in.

One potential solution is to always use smaller constants depending on whether the interaction is mouse or touch based. The only reasonable choice is to use the pointer device kind and not target platform - same platform can have different input sources. This requires exposing the pointer device kind in a few new places in several of the gesture detectors, and using the enum to compute the correct hit slop from an expanded set of constants.

This almost works, however there are a few places (notably ListViews) which uses the touch hit slop as a default value in scroll physics. It does not seem like it will be easy to disambiguate a user provided scroll physics constant from the default and/or adjust it somehow - this might require significant changes to scroll physics which I have left out of this PR.

This PR does not adjust:

kTouchSlop used in scroll_physics.dart's minFlingDistance
kTouchSlop used in PrimaryPointerGestureRecognizer/LongPressGestureRecognizer

* add language version 2.8 in packages/flutter

* enable non-nullable analyzer flag

* Update project.pbxproj files to say Flutter rather than Chromium

Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.

* Update the copyright notice checker to require a standard notice on all files

* Update copyrights on Dart files. (This was a mechanical commit.)

* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.

Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).

* Clean up the copyrights in non-Dart files. (Manual edits.)

Also, make sure templates don't have copyrights.

* Fix some more ORGANIZATIONNAMEs

Drag from the right is no more
Longpress is now only 100ms instead of 500
Added optional duration field to longpressgesturerecognizer
Added controller field to material scrollbar api
Haptic feedback only triggers when scrollbar is fully expanded
Added haptic feedback when releasing the scrollbar after dragging it

You can drag the cupertinoscrollbar if you pass an active scrollcontroller to the scrollbar.

This reverts commit 572f349f.

- A refactor that moves the semantics declaration from detectors to recognizers to allow custom recognizers to respond to semantic gectures.
- Renames all handlers related to semantics from Gesture* to Semantics*.

* Revert "Revert "Redo: Add buttons to gestures (#31819)" (#31912)"

This reverts commit 60a1b2b9.

This reverts commit fea2c7d6.

* Revert "Revert "Add buttons to gestures (#30339)" (#31801)"

This reverts commit 8fd7fa49.

* Synthesise kPrimaryButton for unknown devices

* Change TestPointer to a better API

This reverts commit 727e7e82.

* Callbacks of tap, long press, drag, and double tap GR respond to only primary events.
* Add "secondary" callbacks to tap.
* Recognizers only compete on events if there are any related callbacks.
* Add "kSecondaryButton" constant.

* add onLongPressUp geasture which is fired when a long-press ends