A morse/tap-hold key resolved as a tap by flow-tap fired its tap action
and then, on release, removed itself from the held buffer, leaving no
trace. A subsequent press-and-hold of the same key was therefore a
brand-new press and resolved to the plain hold action instead of the
hold-after-tap continuation, so e.g. a "tap, then press-and-hold to
repeat the tap action" gesture only worked when the first tap had been
resolved by the early-fire path (which does leave an EarlyFired
breadcrumb), not by flow-tap. Whether flow-tap kicked in depends on how
recently other keys were pressed, so the behaviour was inconsistent.
Give flow-tapped entries their own held-buffer state (FlowTapped) and,
on release, downgrade them to EarlyFired when the key has a
hold-after-tap action, exactly like the early-fire path. Plain tap-hold
keys gain nothing from a breadcrumb so they are just removed as before.
Adds a regression test.
Stacked on #845.
A tap that gets resolved by flow-tap (rather than by early-fire) drops the key out of the held buffer the moment it's released. On a tap-dance key I have configured as tap = Backspace / hold = Shift / hold_after_tap = Backspace - rapidly tapping and then holding to repeat-delete only worked sporadically.
Fix: flow-tapped entries get their own held-buffer state, FlowTapped, and on release they downgrade to EarlyFired if the key has a hold_after_tap action, the same thing early-fire already does. Plain tap-hold keys have no hold_after_tap, so nothing changes for them.
I put this in a separate state rather than reusing the ProcessedButReleaseNotReportedYet release arm, since that arm also fires for permissive-hold and unilateral-tap resolutions and I'd rather not special-case those.