Consider splitting Enter into multiple actions

[rachel-fenichel]

I am about to add another meaning for the enter key: when moving a block, pressing enter will place the block at its current location. I was going to just wire it in to handleEnterForWS but as this PR is now in-flight it occured to me that a better approach is to do what we should eventually do anyway, and make it a completely separate action. Similarly, I think the several unrelated activities here should be split in to separate actions:

1. One which, when on a flyout button, presses the button.
2. One which, when on a flyout stack, creates new block(s) on the workspace.
3. One which, when on a field, opens the field editor.
4. One which, when on a connection or the workspace, runs the insert action (this should be in insert.ts)
5. One which, when none of the above apply, shows the help message about the context menu.
   • This needs to be registered first, since shortcuts are tried in the reverse of the order they are registered in.

It might be reasonable for 1 and 2 to be kept as part of a single action, but the other three are unrelated and ought to be separated out. (No objection to doing this as part of a separate follow-up PR, or even just filing a bug to do it later.)

Originally posted by @cpcallen in #306 (review)

See comments further down for decision on final implementation

[kmcnaught]

I have not been paying attention to any of the Action system implementation discussions, so this comment may not be relevant / at the correct level of abstraction, but fwiw me and Matt decided for now that for the MakeCode shortcuts dialog, Enter would be described as Edit or Confirm. I think most of the Enter actions that we are proposing fall broadly into one of those meanings, and it may be helpful to think them in that way, whether from a UX perspective or an implementation-grouping perspective.

e.g.

• press Enter on block in flyout (confirm we are inserting this block)
• press Enter on a connection (edit code here, via an insertion)
• press Enter on a field (edit this field)
• press Enter on a block that's in a moveable state (confirm placement of this block)

[maribethb]

If the actions are separated out, then you either have to implement some kind of priority system, or you let one keypress activate multiple actions, and when you want to add a new one, you have to go read across possibly several files to figure out what happens when you press enter.

A happy medium would be keeping one action per key, but splitting out each of these into their own function calls (which could potentially live in separate files if desired) which are called from one action. Suggestion from @gonfunko

[cpcallen]

If the actions are separated out, then you either have to implement some kind of priority system, or you let one keypress activate multiple actions, and when you want to add a new one, you have to go read across possibly several files to figure out what happens when you press enter.

It's probably worth noting that the existing keyboard shortcut system already has a priority system, albeit a simple one: shortcuts are tried in reverse order of registration, with shortcuts being able to handle or decline to handle a keystroke via either their precondition function or their main callback, and that the codebase already takes advantage of this in several situations, most relevantly with regard to the enter key and arrow keys:
PR #317 (landed in #352) created several actions bound to the same keys as existing actions, including the Finish move action that does not interact with handleEnterForWS.

I believe separate actions bound to the same key are preferable to single actions with switch statements for a number of reasons (that were perhaps only partially explained in RaspberryPiFoundation/blockly#8788):

• It makes implementation of individual actions independent of each other.
• It makes it feasible to provide context-specific help for actions, where the help can identify precicely what action a given key will perform in any given situation, and can do so using the same mechanism that be make that determination when the key(s) are actually pressed.