Fix arrows navigation in the block more options menu

[afercia]

Description

Fixes the arrows navigation in the blocks More Options menu after recent changes in #7199

The new slot/fill implementation of the first menu item broke arrows navigation, for more details please refer to the related issue #7443

This PR tries to fix it passing the deep prop, which makes the menu get also the focusable element that are not direct children of the menu.

Also, to make sure the <div> element used by Slot is ignored by assistive technologies and the accessibility tree is "flattened" and made only by menu > menuitem, it uses a role="presentation" on the div. As with all the ARIA things, this doesn't affect anything for browsers as it's only used by assistive technologies. See the ARIA Authoring Practices, where role="none" (alias of presentation) is used to flatten the tree:

• https://www.w3.org/TR/wai-aria-practices/#menu
• https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-2/menubar-2.html
• https://www.w3.org/TR/wai-aria-1.1/#presentation

Ensuring to flatten the tree structure is important for the way assistive technologies perceive a menu, for example one of the reasons is they calculate and announce the number of items in the menu and their position:

How has this been tested?

• npm test and updated snapshots
• tested with different browser / screen reader combos

To test:

• open a block More Option menu either by clicking on it or using the keyboard
• using the arrow keys, navigate through the menu items and check navigation works correctly

Fixes #7443

[aduth]

@youknowriad Do you happen to recall the context for why deep was needed as part of its introduction in #3303 ? I think we should just remove the prop and have this be its default behavior.

[youknowriad]

@aduth I don't think there was a strong argument for it. It was just incidental to the fact that we have several levels of containers sometimes. And adding role="representation" is not always the answer because of the fact that the components should be independent from each other and sometimes adding a role="representation" to a DOM element should be a decision made within the component as a standalone unit instead of adding it just to satisfy the fact that the component is wrapped with a menu which can be true now, but since the component is reusable might not be always the case.

[aduth]

Pushed c8f558f to remove the deep prop. LGTM if LGTY.

[afercia]

For reference: the div with role-presentation could go away if #7231 gets merged.