Improve editor and toolbar accessibility

[putnokiabel]

Note: This PR continues #2705, which was automatically closed when its head branch master was renamed to fix_accessibility. Same changes, same discussion topic.

Description

Fixes #2531 .
This PR bundles two accessibility fixes for the editor and its toolbar.

1. Toolbar buttons not labeled for screen readers

The buttons in the toolbar are currently not accessible and not labeled correctly when using screen readers (e.g. VoiceOver). This is due to not using the tooltip value on the underlying IconButton from Material.

Changes:

• Allow passing through the tooltip value to the underlying button in ToggleStyleButton (so it's accessible in semantics / VoiceOver)
• Set the correct tooltip value in SelectHeaderStyleButtons. The current approach only allows for setting a single tooltip (same across all header style buttons) which is obviously useless for blind users. This PR fixes this by setting the tooltip to the value displayed on the button (N, H1, H2, etc).

How to test:
Run an app with a toolbar via Xcode, then tap Xcode -> Open developer tool -> Accessibility, and verify that on main, the toolbar buttons don't have tooltips (regardless of tooltips set in ButtonOptions). With this PR, the user of the plugin can set tooltips via the various ButtonOptions.

2. Typing broken on Flutter Web when semantics is enabled (#2531)

When semantics is enabled on the web — via SemanticsBinding.instance.ensureSemantics(), a screen reader, or Tab navigation — the Flutter engine only creates and attaches its editable DOM element (<textarea>) to a semantics node that carries the text-field role and reports focus. The editor drives the IME as a custom TextInputClient but published only an empty Semantics() node, so there was no keyboard target and typing silently failed (only Tab reached the shortcut handler). This makes the previous workaround (autoFocus: true) ineffective and blocks E2E tooling (Playwright/Appium/Maestro) that requires semantics.

Changes:

• Publish a text-field semantics node on the editor, mirroring RenderEditable: textField / multiline / enabled / focused / onFocus plus onSetText / onSetSelection, with excludeSemantics so it is the single leaf the engine attaches its editable element to.
• Rebuild on focus changes on the web so the node's focused flag stays in sync — the engine attaches (and DOM-focuses) the element only while the node reports focus, which is what makes keyboard/Tab-driven focus able to type.
• Scoped to web + editable editors, so other platforms keep driving the IME through the regular flutter/textinput path and keep their existing content semantics unchanged.

How to test:
Run the minimal reproduction from #2531 with flutter run -d chrome (it calls SemanticsBinding.instance.ensureSemantics() in main) and verify text can now be typed into the editor. Verified in a real Chrome that the editor exposes a single text-field semantics node whose focused flag tracks the editor's FocusNode.

Type of Change

• ✨ Feature: New functionality without breaking existing features.
• 🛠️ Bug fix: Resolves an issue without altering current behavior.
• 🧹 Refactor: Code reorganization, no behavior change.
• ❌ Breaking: Alters existing functionality and requires updates.
• 🧪 Tests: New or modified tests
• 📝 Documentation: Updates or additions to documentation.
• 🗑️ Chore: Routine tasks, or maintenance.
• ✅ Build configuration change: Build/configuration changes.