Keyboard: ignore host Option-level characters on macOS - #2159

Addresses #797 and #974 (and the macOS side of #1331, partly - see the bottom).
Not using a closing keyword, since none of those tickets is only about this.

On macOS, in CHARACTER mapping mode, GRAPH and CODE combinations produce the
wrong MSX character or nothing at all. Reported since 2010, and reproducible
today.

Cause

Both Option keys are MSX modifier keys for us: left Option is GRAPH
(processGraphChange on SDLK_LALT), right Option is CODE/KANA by default.
But the host also uses Option to select an alternate character from the
keyboard layout, and it does so before openMSX sees the key. So option+f
reaches us as U+0192, not as f.

In CHARACTER mode that character is looked up in the MSX keymap. Whenever it
happens to exist there, we press the keys that produce that character on the
MSX rather than the key the user actually hit.

That explains a detail which had made this look erratic: it depends on whether
the host's Option-level character exists in that machine's character set. On a
Toshiba HX-10, holding GRAPH and pressing F G H J:

                             MSX keys pressed
  KEY mode (correct)         CHARACTER mode (before)
  Option+F  [F, GRAPH]       [1, CODE, GRAPH]      <-- wrong
  Option+G  [G, GRAPH]       [G, GRAPH]
  Option+H  [H, GRAPH]       [H, GRAPH]
  Option+J  [J, GRAPH]       [J, GRAPH]

Only F is wrong, because U+0192 is part of the MSX character set so the lookup
succeeds. U+00A9, U+02D9 and U+2206 are not, so the lookup fails and the
existing fall-back to key-to-matrix mapping already does the right thing. Which
keys break therefore varies with the host layout and the emulated machine's
character set, which is why the reports each name a different set of keys.

Fix

Ignore the host's interpretation while such an Option key is held, and use that
same key-to-matrix fall-back. This is exactly what SDL3 does for us through
SDL_HINT_MAC_OPTION_AS_ALT, whose ReplaceEvent() rebuilds the NSEvent using
charactersIgnoringModifiers; that hint does not exist in SDL2. Combinations
with Command or Control are left alone, matching SDL3, so the Cmd+I -> Insert
handling and the hotkeys are untouched. KEY and POSITIONAL mode already force
the unicode to zero, so nothing changes there, and on non-Apple builds the test
folds to false.

How it was verified

Driven against a real emulator run with synthetic host key events. Ordinary
CGEventCreateKeyboardEvent() cannot reproduce this: it computes the event's
character payload from the keycode alone, so a synthetic option+f carries f
and the bug never appears. Using CGEventKeyboardSetUnicodeString() to supply
the character macOS actually produces replays the real event exactly - the
resulting kbd_trace_key_presses output matches the trace posted from real
hardware in #797 value for value:

unicode: 0x0192 (f-hook)  keyCode: F  keyName: F+ALT
unicode: 0x00a9 (c)       keyCode: G  keyName: G+ALT
unicode: 0x02d9 (dot)     keyCode: H  keyName: H+ALT
unicode: 0x2206 (delta)   keyCode: J  keyName: J+ALT

The oracle is KEY mapping mode, which both #797 and #974 report as working. The
check reads the emulated key matrix rather than the screen, so it does not
depend on character sets or screen mode. After the change, CHARACTER mode
presses the same MSX keys as KEY mode for all four combinations, over repeated
runs.

Also checked unchanged:

• the CODE/KANA lock traces from Keyboard: don't auto-toggle CODE/KANA lock while that key is held down #2158, all three mapping modes;
• plain and shifted typing, and accented characters via the type command
  (heloHELO and e-acute u-diaeresis come out correctly).

Not covered

Host dead keys. option+e arms a composition in the host's input context, and
the composed character then arrives with the next keystroke, which no longer
has Option held, so nothing on our side can distinguish it. Only the SDL3 hint
prevents the composition being armed at all. That is the remaining macOS half
of #1331.