feat: Make fields focusable

[BenHenning]

The basics

• I validated my changes

The details

Resolves

Fixes #8922
Fixes #8929
Fixes part of #8771

Proposed Changes

This PR introduces support for fields to be focusable (and thus navigable with keyboard navigation when paired with downstream changes to LineCursor and the keyboard navigation plugin). This is a largely isolated change in how it fundamentally works:

• Field was updated to become an IFocusableNode. Note that it uses a specific string-based ID schema in order to ensure that it can be properly linked back to its unique block (which helps make the search for the field in WorkspaceSvg a bit more efficient). This could be done with a globally unique ID, instead, but all fields would need to be searched vs. just those for the field's parent block.
• The drop-down and widget divs have been updated to manage ephemeral focus with FocusManager when they're open for non-system dialogs (ephemeral focus isn't needed for system dialogs/prompts since those already take/restore focus in a native way that FocusManager will respond to--this may require future work, however, if the restoration causes unexpected behavior for users). This approach was done due to a suggestion from @maribethb as the alternative would be a more complicated breaking change (forcing Field subclasses to properly manage ephemeral focus). It may still be the case that certain cases will need to do so, but widget and drop-down divs seem to address the majority of possibilities.

Important: Inputs are not explicitly being supported here. As far as I can tell, we can't run into a case where LineCursor tries to set an input node, though perhaps I simply haven't come across this case. Supporting Fields and Connections (per #8928) seems to cover the main needed cases, though making Inputs focusable may be a future requirement.

Reason for Changes

This is part of an ongoing effort to ensure key components of Blockly are focusable so that they can be keyboard-navigable (with other needed changes yet both in Core Blockly and the keyboard navigation plugin).

Note that #8929 isn't broadly addressed since making widget & drop down divs manage ephemeral focus directly addresses a large class of cases. Additional cases may arise where a plugin or Blockly integration may require additional effort to make keyboard navigation work for their field--this may be best addressed with documentation and guidance.

Test Coverage

No new tests have been added. It's certainly possible to add unit tests for the focusable configurations being introduced in this PR, but it may not be highly beneficial. It's largely assumed that the individual implementations should work due to a highly tested FocusManager, and it may be the case that the interactions of the components working together is far more important to verify (that is, the end user flows). The latter is planned to be tackled as part of #8915.

Documentation

No new documentation is planned, however it may be prudent to update the field documentation in the future to explain how to utilize ephemeral focus when specifically building compatibility for keyboard navigation.

Additional Information

This includes changes that have been pulled from #8875.

[BenHenning]

Self-reviewed changes not included from #8939.

[BenHenning]

PTAL @rachel-fenichel. Feel free to use BenHenning#5 to see the exact diff with #8939 which will hopefully make the review easier.

[rachel-fenichel]

LGTM--the exact diff is not that large and matches the designed behaviour.

[BenHenning]

Self-review confirming this has the same changes as BenHenning#5.

[BenHenning]

See #8938 (comment) for why this is being merged now.