[WIP] Text editing gestures - #84232

Requirements:

Given the assumption that we want something analogous to keyboard shortcuts, things we want to enable with the new system:

GestureRecognizer Overriding (analogous to shortcuts overriding).

1. disable an existing gesture,
2. add new supported gestures. The user-defined gesture recognizers need to have access to the text field instance it will be added to, so it can perform text editing actions. ()
3. override an existing gesture. The default gesture recognizers defined for SelectableText/TextField/CupertinoTextField's gesture recognizer implementation are actually similar -- the biggest difference comes from the target platform.
   - developers may need a way to get a hold of the super gesture recognizer implementation in the override, so they can add things with ease (e.g., for adding a Feedback.longPress())
   - a gesture recognizer can be overridden multiple times: a library should be able to provide a set of predefined gestures for a custom input field built on top of TextField. And the user should be able to further override this.

GestureEvent (e.g. onTapUp) -> Intent(s) mapping.

• A gesture event should be able to invoke actions associated with multiple intents (e.g., selectWord + show context menu)
• Same as 3. in the previous section

Intent -> Action mapping.

• Actions need access to the text field/EditableTextState/
• We want the ability to override the behavior of an Action easily: in a date field that accepts mm/dd/yy I want select word to just expand to mm or dd or yy.
• Similar to gesture recognizers, preferably there should be a way to get a hold of the super implementation of an Action.

Some observations (some should probably be addressed in separate PRs):

1. Most of the gesture recognizers need to be installed on the EditableText instead of the text field. For instance, for a single-line text field that occupies the entire screen, it doesn't seem to make sense to change the selection when the gesture's initial pointer down event landed far away from the text area (the text area is usually going to have a height that's significantly smaller than the input decorator in this case).
   Initially the gesture recognizers were installed on EditableText but because of the number of test failures caused by this I had to move them to TextField, etc.
2. shouldShowSelectionToolbar is a bit confusing. We should probably infer it from the gesture's pointer device kind/button, gesture type, and the target platform, instead of having a publicly writable flag that's difficult to reason about.
   3 RenderEditable & EdiableText should not be where the gesture recognizers are installed, because they generally don't have enough margin between the glyphs and the edge of the gesture recognizers.

Some potential problems with this approach:

1. For library authors, it's difficult to override the default behavior. For instance SelectableText handles some gestures differently. To provide these SelectableText specific defaults, we have to put a TextEditingGesture in SelectableText, making those gesture recognizers unconfigurable from outside. (Maybe we can add a gestureRecognizers parameter to the text editing widgets and let it have the highest precedence)
2. Overwriting the default gesture recognizers is unnecessarily verbose. For instance Feedback is defined in the material library. It takes a lot of code to add a Feedback to the default long press callback (from the widget library). So is "onTap".

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.