Call handler of keybinding even if there are multiple matches

Currently if multiple matching shortcut handlers are found (after filtering) only one handler is called (the one that was defined last). This is implemented by this logic of key processor:

https://github.com/prompt-toolkit/python-prompt-toolkit/blob/07412a37b38dd70a3d63f2966a21f0a645133264/src/prompt_toolkit/key_binding/key_processor.py#L185-L187

In other words currently the bindings (after filtering) are always exclusive.

There are some limitations with this approach:

• Sometimes, it is beneficial to execute two actions on the same keystroke press (but allow user to override one without affecting the other).
• Sometimes defining a filter to handle all edge cases is too difficult as it does not have an access to current state (application nor event), but the handler can get both as it gets the event as an argument

Would it be in scope to have a new option for bindings that allows the handler to be called even if another binding matches? This could have public interface similar to eager option, for example:

@bindings.add('a', exclusive=False)     # default would be `exclusive=True`
def binding_2(event):
    ...

and the logic could be adapted to:

 # Exact matches found, call handler.
 if not is_prefix_of_longer_match and matches:
     exclusive_matches = [match for match in matches if match.exclusive]
     non_exclusive_matches = [match for match in matches if not match.exclusive]
     # fire only one exclusive match (this guarantees backward-compatibility)
     if exclusive_matches:
         self._call_handler(exclusive_matches[-1], key_sequence=buffer[:])
     # call all non-exclusive matches (regardless of the exclusive matches)
     for match in non_exclusive_matches:
         self._call_handler(match, key_sequence=buffer[:])

The proposed logic does not stop after the exclusive match is found as stopping there would still lead to the problem that motivates this proposal: newly added handler would suppress a built-in handler. This suggests that a different name could be more appropriate, for example unconditional=True.

For context, here is the downstream issue: https://github.com/ipython/ipython/issues/14070 and workaround: https://github.com/ipython/ipython/pull/14080

Start with src/prompt_toolkit/key_binding/key_processor.py around lines 185-187, then inspect the binding API used by bindings.add(...). Review the linked IPython issue and workaround to clarify the intended semantics and option name. Done means defining backward-compatible behavior for multiple matching handlers, including user overrides and non-exclusive execution.