Enter lyric melisma with the underscore key on non-US keyboards

[jiyimeta]

Refs #14914 (the Japanese-keyboard report; reproduced here on macOS) and #16492 (AZERTY).

A lyric melisma is entered with the underscore character, but its default shortcut is Shift+-, which only produces _ on US‑ANSI keyboards. On layouts where _ is a dedicated key (e.g. Japanese JIS on macOS) or is produced by a different combination (French AZERTY, German QWERTZ, …), the shortcut layer never routes the underscore key to the add-melisma action, so a melisma cannot be entered at all.

This handles the underscore key directly in the notation view while editing lyrics: Qt::Key_Underscore with no modifiers is claimed in shortcutOverrideEvent() and dispatched to add-melisma in keyPressEvent(), bypassing the keyboard‑layout‑dependent shortcut path. The dispatch is deferred to the next event‑loop turn (matching how shortcut‑driven actions run) so add-melisma's edit teardown does not run while the key event is still being delivered. Shift+- keeps working on US layouts, and non‑lyrics text editing is unaffected — the intercept is gated on actively editing a Lyrics element.

Scope / testing. Validated on a macOS JIS keyboard, where the dedicated _ key arrives as Key_Underscore with no modifiers: pressing it now creates and extends a melisma (incl. consecutive presses); Shift+- still creates a melisma on a US layout; typing _ in non‑lyrics text still inserts a literal underscore.

Note that #14914 was reported on Windows, where _ is produced as Shift+\ (i.e. with a modifier). That path likely delivers a different key event and is not covered by this no‑modifier intercept, so it probably needs separate handling/verification on Windows. I deliberately used Refs rather than Resolves so #14914 isn't auto‑closed before the Windows case is confirmed.

I couldn't add a unit test: the change lives in the live key‑event path (shortcutOverrideEvent/keyPressEvent) and there's no existing harness for synthesising QKeyEvents through the notation view. Happy to add one if you can point me at a suitable place.

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it relates to
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)