Add support for locking keys

[benoit-pierre]

Summary of changes

Closes #1161. Depends on #1276 (included).

How it works:

• a regular {#combo} key combo now can end with keys left in the pressed state
• a new {##combo} key combo syntax allow continuing a preceding combo
• otherwise, sending a new combo, sending backspaces, or sending a string will automatically disengage previously held keys
• when keys are being held, the keyboard machine is fully suppressed (the whole keyboard is suppressed, all keys, including events with modifiers)
• that's pretty much it!

I ended up moving some of the key combo handling one level higher, in the engine: the KeyboardEmulation.send_key_combination method no expect a pre-parsed list of event to send (pairs of [pressed: boolean, key_code]), parsing and validation is done in the engine.

Because the Windows implementation does not monitor keyboard layout changes though events, but instead would refresh the layout before sending a key combo / backspaces / string, the output instance can now be used as a context manager:

with output:
    output.send_backspaces(...)
    output.send_string(...)

The layout is refreshed on __enter__ on Windows. And on Linux, display.sync() is called at __exit__.

The (keyboard) machine suppression now has 3 possible modes:

• SUPPRESSION_NONE: no suppression (e.g. when output is disabled)
• SUPPRESSION_PARTIAL: only suppress some keys (standard mode when output is enabled)
• SUPPRESSION_FULL: full suppress the keyboard: only used while a combo is active (held keys)

TODO:

• more tests, including actually testing it works as expected on Linux/Windows/macOS
• finish TODO...

Pull Request Checklist

• Changes have tests, but more needed
• News fragment added in news.d. See documentation for details

[user202729]

Note: need a rebase. (on the dependent pull request)

[petercpark]

I'm interested in this pull request. Can we make it happen?