Use ScanCodes instead of KeyCodes for Keyboard mapping

[rastla]

Fixes the issue described in #8033
US keyboard layout should be unaffected by this.

DE keyboard layouts would now be able to use more keys (^ ß ´ ü ö ä #).
Similar for other keyboard layouts like FR.

Keys.W and Keys.A would now map to Keys.Z and Keys.Q in the FR keyboard layout.
So if you map your walking to WASD via the Keys enum, then players with FR layout will be able to walk with ZQSD - which is the preferred way.

This also means that the Keys enum is only representative for the US layout (it also already included only US keys, so that shouldn't be much of an issue I assume).

Meaning, although you are pressing ^ on the DE keyboard, it is detected as Keys.OemTilde (~)
Meaning, although you are pressing ö on the DE keyboard, it is detected as Keys.OemSemicolon (;)
You get the idea

[stromkos]

The problem with your PR is that scan-codes vary per keyboard layout. In the DE keyboard Z = English Keyboard Q. The scancodes are the same. This is a discrepancy is normally resolved via the OS; SDL simply passes the scan-codes, ignorant of the keyboard layout.

This PR breaks the existing system in 2 ways: It breaks existing keyboard mappings, and loses the ASCII mapping.

[rastla]

The problem with your PR is that scan-codes vary per keyboard layout

To quote yourself 😄

The scancodes are the same

The scancodes stay the same, regardless of keyboard layout. It's the keycodes that change with the keyboard layouts.
Which is exactly what this PR is about.

This PR breaks the existing system in 2 ways: It breaks existing keyboard mappings, and loses the ASCII mapping.

It doesn't break the US keyboard layout, which is the only one that works properly.
It kind of breaks the keyboard mappings of non-US keyboard layouts for existing projects.
It also provides a fully usable keyboard for non-US keyboard layouts, which isn't possible without this PR.

Maybe it would be better to offer the ScanCode functionality in addition to the existing KeyCode mapping?

[Epicguru]

Has there been any consideration towards merging this PR? It seems like a straight upgrade, assuming that Sdl accurately reports scancodes accross desktop platforms.
Most modern game engines/libraries use this aproach, such as Unity which recently made 'physical keys' the new default (https://docs.unity3d.com/Manual/class-InputManager.html).

The way I see it (again assuming that it works as intended), it will have no negative impact on the current standard US layout, but it will provide a better default behaviour for non-US layouts.

[mrhelmut]

This solution is incomplete to me. Yes, most libraries made that choice, but Unity does offer an API to get what's actually printed on the physical key depending on the user's layout. Which we don't (and it's a concern whenever you want to display key bindings in a setting menu, for example).

The initial XNA design (and SDL's virtual keys) was to try to fuse those concerns into a single bloat-free API: you get what you expect. It indeed came with a very US-centric view on the problem, but the intent was good to me and I believe that we can still expand on that and be smarter about it to support a wider range of keys.

Anyway, as-is it's a breaking change and can't be considered for the ongoing 3.8 branch.