feat: Commit moves before running keyboard shortcuts.

[gonfunko]

This PR fixes #534 by registering a keyboard shortcut under the key combos of all existing keyboard shortcuts that commits the in-progress move before returning control to the corresponding real keyboard shortcut. To fully function, this depends on RaspberryPiFoundation/blockly#9109; without it, moves will be commited, but the underlying/real shortcut action may not run.

[rachel-fenichel]

Please add this test:

• start a move with keys
• press an arrow key twice
• press c
• press an arrow key twice
• check that the block is in the expected location

[microbit-matt-hillsdon]

Also needs KeyCodes.SPACE from the finish move action alongside ENTER.

Potentially these could be pulled from a list of the move actions from move.ts? Would be helpful in future as we hope to add UI with the ability to rebind shortcuts (though these ones are perhaps less likely to change than some).

[rachel-fenichel]

And we do anticipate that when all of the keyboard nav code makes it into core, the shortcut actions will directly cancel moves. This setup is necessary because some shortcuts are in core and some are in the plugin. We will keep UI rebinding in mind for design work on that.

[gonfunko]

We don't actually need space, because this shortcut finishes the move itself; Enter is there to support command-enter to bring up the contextual menu, not to commit the move. But we do need Escape to abort the move, so I added that in (and cleaned up this shortcut in the new common cleanup method introduced in #561).

[microbit-matt-hillsdon]

Would be great to get #561 in first and clean up this new shortcut in the new common clean-up method, as presumably it should be cleaned up on abort too. Or call in both places here and I can fix conflicts with the other PR.

[rachel-fenichel]

Looks good, and I'm okay with merging as-is since this is a blocker.

And a tag for RaspberryPiFoundation/blockly#8915 in case you don't get to writing that test today.