Fix tap-hold processing for multiple hold actions #24002

[orthodogz]

Description

This PR purpose is to fix the problem with processing multiple hold actions and one tap action when PERMISSIVE_HOLD is defined and TAPPING_TERM hasn't elapsed. When such conditions are met, keys not fired, contrary to the PERMISSIVE_HOLD decision mode and the firmware continues to wait for new actions in reset state of process_tapping SM. To trigger hold actions selection user have to tap amount of keys equal to holded keys. This PR fix this by adding deferring tap key entity that indicate that processing of hold actions must be continued till tap key. As side effect of this fix, bigger number of simultaneous hold actions now can be fired in PERMISSIVE_HOLD style decision: (WAITING_BUFFER_SIZE - 1) vs old ceiling(WAITING_BUFFER_SIZE/3).
This is just a draft and I totally not qualified enough for this so I will be happy if someone with experience take a look at the issue and make more consistent alternation in process_tapping if appropriate.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• [Feature Request] Change permissive-hold behavior for multiple tap-hold keys #24002

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).