[Bug] Early release of Tap-Hold key when tap.count > 1

Describe the Bug

When chaining a quick double tap of a Tap-Hold key with a tap of an other Tap-Hold key, the firmware releases the double tapped key before that key is physically released, and then triggers an extra key release when the key is physically released (see attached debug report). I added a debug entry in process_record_user to get a better sense of what's happening. As you can see, on line 40, the quickly double tapped key is released early by the firmware while the physical key is still pressed. At the end of the report, on line 70, when the physical key is released, the firmware processes an extra key release.

report.txt

Keyboard Used

No response

Link to product page (if applicable)

No response

Operating System

No response

qmk doctor Output

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

I started to fix this, taking advantage of the registered_taps buffer (currently only used by the chordal hold and flow tap features). I had to extend the data type of the buffer to also remember the current tap count.

One issue I'm currently facing is when a combo resolves to a Tap-Hold keycode. In that case the keypos of the corresponding keyreport is set to (0,0), clashing with the key at that position and making it impossible to uniquely identify different combos. My dirty solution to that problem is to "cast" the combo index into a keypos, just before calling action_tapping_process from release_combo and dump_key_buffer, and then check the type of event I'm dealing with to choose how to interpret the keypos value stored in registered_taps.

Here is a link to the changes I made so far: https://github.com/qmk/qmk_firmware/compare/master...shards-of-wisdom:qmk_firmware:fix-quick-tap.

P.S.: this my first time contributing to an open source project.