feat: Parameterised Mod Morph and Tap Dance

[Nick-Munnich]

General idea is to have a binding-params array property which maps parameters input to the behavior to the behaviors found in the bindings array. Bit flags and some macros to tidy it all up.

Docs are included, I decided to substitute the references to the non-parameterised version with the parameterised one in the interest of "one way to do it". Current one was moved to a footnote.

In general I think the approach and user experience side of things is good. May add more tests. Unsure whether documentation needs further reworking or if the non-parameterised version should remain prominent.

PR check-list

• Branch has a clean commit history
• Additional tests are included, if changing behaviors/core code that is testable.
• Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
• Pre-commit used to check formatting of files, commit messages, etc.

TODO:

• Identify a solution to the hold-tap issue.
• Add behavior metadata for Studio.

[caksoylar]

I think this is pretty nice. A few things worth discussing:

• Forcing mod-morphs and tap-dances to always have two parameters prevents them from being used in hold-taps, or inside parametrized mod-morph/tap-dances. This is a big limitation, so it might be worth keeping around zero-param versions as the main variants.
• These are a bit inconsistent w.r.t. parametrized macros, they are more flexible so we can't easily unify them. One thing we can do is switch to PLACEHOLDER instead of MACRO_PLACEHOLDER in the macro docs.

[caksoylar]

This is worded slightly differently compared to mod morph, it is probably worth keeping them same.

[Nick-Munnich]

The slightly different wording is due to one of them being of fixed length 2, while the other can vary. If this was extended to hold-tap and macros I'd use the mm wording for hold-tap and the td wording for macros.

[Nick-Munnich]

* Forcing mod-morphs and tap-dances to always have two parameters prevents them from being used in hold-taps, or inside parametrized mod-morph/tap-dances. This is a big limitation, so it might be worth keeping around zero-param versions as the main variants.

You should be able to use them inside the others with appropriate 0s being passed in the right places. I'll add some more tests to be sure.

EDIT: parameterised nesting works fine, hold-tap is an issue that needs to be discussed to find the right resolution.

* These are a bit inconsistent w.r.t. parametrized macros, they are more flexible so we can't easily unify them. One thing we can do is switch to `PLACEHOLDER` instead of `MACRO_PLACEHOLDER` in the macro docs.

I think that both hold-tap and parameterised macros could be adjusted to use a binding-params, I just wanted to get the ones which aren't yet parameterised done before working on (understanding and) adjusting macro and hold-tap. Definitely agree on switching away from MACRO_PLACEHOLDER.