Fix Ctrl+A/C/X/V shortcuts in EditableText on non-Latin keyboard layouts

[Farori]

Objective

Fixes #24997.

Select All / Copy / Cut / Paste shortcuts in EditableText
(bevy_ui_widgets) don't work while a non-Latin keyboard layout (Cyrillic,
Greek, Hebrew, Arabic, ...) is active: the shortcuts were matched only
against the layout-dependent logical_key, so with e.g. a Russian layout
Ctrl+C arrives as Key::Character("с") and never matches "c".

Solution

Use the hybrid matching strategy approved in the issue (the convention used
by most toolkits and browsers):

• match the layout-aware logical_key first, keeping AZERTY/QWERTZ/Dvorak
  shortcut conventions intact;
• fall back to the physical key_code (KeyCode::KeyA/KeyC/KeyX/KeyV) when
  the logical key is not an ASCII character.

The check is extracted into a matches_edit_shortcut helper with unit tests.
Behavior for Named keys (arrows, Home/End, Backspace, ...) is unchanged,
and unmatched combinations still propagate.

Longer term, exposing winit's key_without_modifiers in bevy_input would
allow a more principled solution: #25055.

Testing

• cargo run --example text_input on Windows 10 and Linux: with a
  Russian/Ukrainian layout active, Ctrl+A/C/X/V now work; on US QWERTY the
  behavior is unchanged; named-key shortcuts and plain text input are
  unaffected.
• New unit tests for the helper: cargo test -p bevy_ui_widgets.
• cargo run -p ci -- lints passes.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly ✨