[Feature Request] Need a way to configure unicode tap code delay

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

Context

I'm having issues with some apps not detecting keys sent with tap_code(). I must set TAP_CODE_DELAY to at least 15-20ms for those apps to properly detect them. But that has an undesired effect on my unicode keys; since they end up "tapping" 7-8 keys each with that same delay, they take much longer to send, to a point where tapping keys rapidly misses some key presses, especially when tapping the same unicode key multiple times rapidly.

To fix that, I'd like to have a way to use a different delay for unicode taps. I have 2 solutions in mind:

Solution 1: UNICODE_TAP_DELAY

Add a configurable definition, UNICODE_TAP_DELAY, to use in unicode_input_start(), unicode_input_finish(), unicode_input_cancel() and send_nibble_wrapper(). It would default to TAP_CODE_DELAY to keep the existing behavior by default. Would add a send_nibble_delay(), similar to send_nibble(), but calling send_char_with_delay(), and use it in send_nibble_wrapper().

Solution 2: Make send_char() weak

Adding __attribute__((weak)) to send_char() would allow customizing it with a different delay, just like it can be done with tap_code(). That solution requires more user code on my end, since I need to override unicode_input_start() and unicode_input_finish() to know I'm registering a unicode key, store that state, and override tap_code() and send_char() to use a different delay.

Conclusion

I prefer solution 1, but solution 2 requires less core changes. Maybe both can be done, making send_char() weak probably can't hurt and would be consistent with tap_code().

I'll happily make a PR with whatever solution is chosen, but I want to make sure we agree on a solution before doing so.