Fix keyboard layout regression for non-QWERTY layouts

[mikker]

Fixes #255 #264

Problem

The keyboard layout regression introduced in v1.17.0 broke support for non-QWERTY layouts (AZERTY, Colemak, Dvorak, etc.). The new KeyMaps system was always using hardcoded US-QWERTY mapping, ignoring the user's actual keyboard layout.

Root Cause

• Controller.charForEvent() unconditionally used KeyMaps lookup instead of respecting event.charactersIgnoringModifiers
• The "Force English keyboard layout" setting existed but was effectively always enabled
• Physical keys were interpreted as QWERTY positions rather than the logical characters they produce

Solution

• Respect user's layout by default: Use event.charactersIgnoringModifiers for printable characters
• Honor the force English preference: Only use KeyMaps when explicitly enabled
• Preserve special keys: Non-printable keys (arrows, escape, etc.) still use lookup table
• Maintain case sensitivity: Both "r" and "R" can trigger different actions

Changes

• Fixed charForEvent() method to branch on forceEnglishKeyboardLayout setting
• Added helper englishGlyph() method for force English mode
• Enhanced preferences UI with explanatory help text
• Added comprehensive unit tests covering both layout modes and case sensitivity

Testing

• ✅ All existing tests pass (no regressions)
• ✅ 7 new unit tests validate keyboard layout handling
• ✅ Tests cover AZERTY, Colemak, case sensitivity, and special keys
• ✅ Both force English modes tested

Impact

• AZERTY users: Physical "A" key now correctly produces "q" instead of "a"
• Colemak users: All letter keys now respect layout instead of QWERTY positions
• All users: "Force English keyboard layout" preference now works as intended
• Backward compatibility: Existing behavior preserved when force English is enabled