Per a recent team meeting to examine how flicks felt, etc, this PR reworks flicks from the form seen in #9909 and #9825 to something that will hopefully feel smoother and more intuitive. To wit:

There may be a bit of fine-tuning to be done (that first reset attempt on the 'i' seems a bit odd), but the following criteria have been met:

1. Flicks now "lock" into a specific direction.
   • Among other things, this allows us to make a nice, smoothed scrolling animation showing how close the user is to activating the flick.
2. This "lock" can be "reset" with a return to the base position.
   • A different flick direction may then be chosen while in the 'reset' state.
   • This has been updated since the recording above; flick-resets are now much cleaner and more reliable.
3. Attempting a flick in an unsupported direction, with no neighboring supported flick to serve as a reasonable alias, results in cancellation.
   • This occurs when the flick attempts to 'lock' its direction.
   • This gets dropped in change(web): gestures polish pass 🐵 #9972, at which point it simply "locks" on the base key until a valid flick direction is input.
4. There is a "fudge factor" around flicks, allowing their activation "reasonably near" to their correct angle.
   • This "fudge factor" also applies for locked-in flicks; the animation (and activation condition) thresholds are based on how much of the actual motion aligns with the locked-in direction.
     • This is done using the principles of vector projection.

There is a "fun" interaction between points 2 and 4 above:

As the flick-reset occurs (due to vector projection) while quite far from the original, base position, and there is no flick available in the new direction, the flick quickly cancels upon reset. That said, if there were a flick available in the new direction (via temp-edit)...

It feels a little abrupt, but not too much so. It's probably "fine"... or at least, low-priority enough that further polish work is "safe" to triage until a later point in time.

Note: I've revised things since the screen capture above, but that was done alongside work on #9972 and is hard to fully display without that. I've gone ahead and rebased the changes originally within #9991 onto this branch and done a git merge -ff-only; its code changes were near-entirely within the same files already changed here, so the review process should be simpler as a result... even if the child PR (#9972) is needed to fully appreciate certain aspects.

As such...

@keymanapp-test-bot skip

User tests will be specified either on #9972 or on its followup #9973.