feat!: Added support for separators in menus.

[gonfunko]

The basics

• I validated my changes

The details

Resolves

Fixes #8752

Proposed Changes

This PR adds support for separators in all Blockly menus, including contextual menus on the workspace, blocks and comments, and in dropdown menus spawned from FieldDropdown.

For contextual menus, separators can be added via the context menu registry in a similar manner to normal menu items:

  const separator: RegistryItem = {
    separator: true,
    scopeType: ContextMenuRegistry.ScopeType.WORKSPACE,
    id: 'whatever-id-goes-here',
    weight: 2,
  };
  ContextMenuRegistry.registry.register(separator);

For FieldDropdown, separators can be added via JSON (or a generator function) by using the string literal separator:

{
  'type': 'field_dropdown',
  'name': 'SOME_DROPDOWN_FIELD',
  'options': [
    ['Normal menu item', 'normal'],
    ['Other menu item', 'other'],
    'separator',
    ['Different menu item', 'different'],
  ],
},

Breaking changes

In general existing code should continue to work, but in order to accomodate typings ContextMenuOption and RegistryItem are now types instead of interfaces. Core and our documentation suggest using these as object literals, as in the example above in this PR description, which will continue to work as-is, but if users have a class that implements either of these interfaces, the implements will need to be removed.

[rachel-fenichel]

Won't this fail if the option is just FieldDropdown.SEPARATOR instead of a tuple?

[gonfunko]

No; option[1] would be "e" in that case, since option would be the string "separator", and the type of "e" is still string.

[rachel-fenichel]

Why remove these two?

[gonfunko]

They're unreferenced in the entire codebase. I suppose this is technically a breaking change, but they feel very implementation detail-y. Happy to revert if you want though.