Make toolbars a single Tab stop by default in the next major

[woksin]

#328 adds arrow-key navigation to Toolbar and ActionMenubar while every tool keeps its own Tab stop. That default keeps the change compatible for a minor release. The WAI-ARIA APG toolbar pattern instead uses one Tab stop, with focus returning to the last focused tool. #328 offers that behavior as an opt-in mode.

Done when

• The next major release makes the single Tab stop the default for Toolbar and ActionMenubar, and the release notes and migration guide describe the change in focus behavior.
• An opt-out keeps the old behavior of one Tab stop per tool.

[woksin]

Update from the 4.19.0 work on #328: 4.19.0 ships ToolbarFocusMode.Arrows (the default) and None. The opt-in single-Tab-stop mode was implemented and then removed before release.

Three review rounds found edge cases in it, all with the same root cause: the navigation hook rewrote tabindex attributes that React also sets from consumer props. When a consumer changed tabIndex to the value the hook had last written, for example -1 on a tool that was not selected, the hook could not see the change. It kept the tool in the roving set and restored the wrong value when the mode ended.

Design for this issue:

• Components-owned tools (ToolbarButton, the ActionMenubar action buttons) read their tabIndex from a toolbar context instead of having the attribute rewritten after render. React then stays the only writer.
• Consumer-supplied children (Toolbar children that are not ToolbarButton, ActionMenubar templates) get a documented rule. Either they opt in through a hook or props that return the roving tabIndex, or widgets keep their own Tab stop. Inputs, selects and sliders must never lose their native keys, and no tool may become unreachable (4.19.0 has specs for both).
• Add ToolbarFocusMode.SingleTabStop in a minor, with this design, before it becomes the default in the major. Adding an enum value is not a breaking change.