MenuToggle does not derive accessible name from visible text children

Description

When MenuToggle renders with visible text children (e.g., <MenuToggle>Actions</MenuToggle>), it does not automatically derive its accessible name from that text. Consumers must manually duplicate the text in an aria-label prop, which is error-prone and violates WCAG 2.5.3 (Label in Name).

WCAG Impact

• 2.5.3 Label in Name — For UI components with visible text labels, the accessible name must contain the visible text. If MenuToggle doesn't derive its accessible name from its children, speech-input users who say "click Actions" may not activate the correct control.

Steps to Reproduce

1. Render <MenuToggle>Actions</MenuToggle> without an aria-label
2. Inspect the element's computed accessible name in browser DevTools or a screen reader
3. The accessible name may not match the visible "Actions" text

Expected Behavior

MenuToggle should derive its accessible name from its text children by default, similar to how a standard <button>Actions</button> does. An explicit aria-label should only be needed for icon-only toggles (kebab menus).

Current Behavior

Consumers must manually provide aria-label="Actions" even when the text "Actions" is already visible in the toggle. Our codebase (ansible/ansible-ui) has hardcoded fallback aria-label values like 'kebab dropdown toggle' and 'dropdown toggle' that don't match the visible text, precisely because the component doesn't handle this automatically.

Jira Issue: PF-4545

Start at the MenuToggle component and inspect how its accessible name is computed when it receives visible text children without an aria-label. Compare this behavior with a standard button and determine how explicit labels should behave for icon-only toggles. Done means text children provide the accessible name by default while explicit aria-label values remain available for icon-only use.