fix(behaviors): Correct macro release state for parametrized macros

[caksoylar]

This PR adds a test for a macro bug where parameter passing isn't working correctly after &macro_pause_for_release, and proposes a fix.

The root cause seems to be that when pre-computing release state in behavior_macro_init, the parameter passing logic of the on-press portion is only partially taken into account. That is, control bindings like &macro_param_1to1 are properly consumed (through the handle_control_binding calls) but whether the parameters are then used by a non-control behavior isn't considered: the release state precomputation does not replicate the resetting of param*_source variables that happens within replace_params during the on-press portion of the bindings. So the fix is to do this reset whenever a non-control behavior is encountered, emulating the replace_params call inside queue_macro.

As an example, in the added test, &kp MACRO_PLACEHOLDER consumes the previous &macro_param_1to1 directive, both before &macro_pause_for_release. But &mo 1 that comes after the release still uses the first parameter because the release state precomputation didn't apply the param*_source resetting logic.

Fixes #2921.

PR check-list

• [x] Branch has a clean commit history
• [x] Additional tests are included, if changing behaviors/core code that is testable.
• [x] 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)
• [x] Pre-commit used to check formatting of files, commit messages, etc.
• [x] Includes any necessary documentation changes.

[nmunnich]

Nice spot. It feels a bit weird to me to apply a fix to every behaviour, though it could be argued that a refactor should happen to treat each behaviour individually. Shouldn't this sort of reset happen after the wait for release?

[caksoylar]

I expect this might also fix #2031, but would need testing to confirm.