Add support for centrally managing and changing DOM focus

[BenHenning]

Check for duplicates

• I have searched for similar issues before opening a new one.

Problem

Core Blockly doesn't currently have a good way to handle the following user flows:

• Ensuring element selection/navigation via the keyboard navigation plugin ties back to DOM focus (which is necessary screenreader support).
• Ensuring that currently focused elements have clear visual indicators (this sort of works today for elements that are selectable, but otherwise we rely on browser focus visual indicators which are very subtle or outright may not work in certain SVG contexts).
• Ensuring that distinct focus 'domains' (e.g. the workspace and toolbox) can represent 'passive' focus (that is, the last element within that logical context that held DOM focus but doesn't currently). This is especially useful for communicating which visual element will receive focus when returning to that context (such as navigating from the toolbox back to the workspace).
• Ensuring cases when focus context needs to be taken temporarily (such as for drop-downs) can be done in a clean way.

Request

RaspberryPiFoundation/blockly-keyboard-experimentation#142 (comment) describes the high-level solution for this, but specifically this issue is meant to track adding (see also the sub-issues):

Alternatives considered

The technical design above has a lot of context on alternative considerations.

Additional context

The technical design above should have all important additional context. #8771 tracks more specific components that need to be updated in order for the system introduced with this issue to be useful. RaspberryPiFoundation/blockly-keyboard-experimentation#142 tracks the work to integrate the new focus system within the keyboard navigation plugin.

[BenHenning]

NB: The current plan is to introduce this functionality in 2 PRs:

• The first for introducing the actual interfaces.
• The second for introducing the FocusManager (which has logic and tests that require much more time to build than just the interfaces).

This approach enables parallel development with #8771, though some of that issue may need to be done practically as part of PR (2) above in order to verify that it actually works (though may not necessarily be checked in or created as a proper PR).