Support for untranslated key codes

[thedmd]

Add support for untranslated key codes (scancodes) for ImGui.

Intention is to provide forward way for ImGui to handle untranslated keys in response to https://github.com/ocornut/imgui/pull/2625#issuecomment-615817830.

I introduced GetUntranslatedKeyIndex to map ImGuiKey_ into io.KeyDown index. Similar to what GetKeyIndex does. Difference is scancodes remain the same regardless of keyboard layout used and correspond to physical placement of the keys.

    IMGUI_API int           GetUntranslatedKeyIndex(ImGuiKey imgui_key);                               // map ImGuiKey_* values into user's key index == io.ScancodeMap[key] if supported, otherwise act like GetKeyIndex

Support for untranslated keys is an optional backend feature controlled by new flag:

    ImGuiBackednFlags_HasUntranslatedKeys = 1 << 4,   // Back-end Platform supports physical keyboard layout mapping to ImGuiKey_XXX.

For backends without support for this feature GetUntranslatedKeyIndex behaves exactly like GetKeyIndex.

PR provide an implementation in imgui_impl_win32.cpp backend as an example. More will be done as this idea mature.

Things I can think of out of the box that should be discussed:

1. Is there a need for functions converting untranslated key to translated one?
2. Should there be a function returning key names like:

   const char* GetKeyName(int key_index);
   
   // ImGui::GetKeyName(ImGuiKey_A) -> "A"
   // ImGui::GetKeyName(ImGuiKey_Z) -> "Z"
   // ImGui::GetKeyName(ImGuiKey_LeftArrow) -> "Left Arrow"
   

   Should GetKeyName be hardcoded, localized and/or system dependent?
3. Scancodes are not portable, so should ImGui provide out of the box mapping from US layout only? image source Maybe most common physical layouts to scancode mapping should be provided? Or one is enough beacause user will be able to pick keys according to default one.

Summing things up:

int g_StrafeLeftKeyIndex = -1;
int g_StrafeRightKeyIndex = -1;
int g_MoveForwardKeyIndex = -1;
int g_MoveBackwardKeyIndex = -1;

void Init()
{
    // Map to WSAD, will map to same physical keys on French, US and others
    // keyboards.
    g_StrafeLeftKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_A);
    g_StrafeRightKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_D);
    g_MoveForwardKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_W);
    g_MoveBackwardKeyIndex = ImGui::GetUntranslatedKeyIndex(ImGuiKey_S);
}

For French keyboard:

With untranslated key support	Without untranslated key support

Please let me know what do you think.

Edit:

Demo for French keyboard layout. I tap keys in same order in both cases.

[thedmd]

@ocornut If you find a minute please confirm that what I got is an intended behavior. Thanks!

[thedmd]

Back to green.

[ocornut]

Update on this (following our work and conversation with thedmd on e.g. #4858 #2625)

TL;DR;

• This isn't actually needed. Because GLFW and SDL backends passed untranslated keycode (the former due to an issue in GLFW, the later due to how we accidentally needed to use scancode for indexing rather than keycode) it opened a conversation on keycodes, which is now resolved.
• The only purpose I can think of right now is to make it easy for portable imgui-code to use WASD type of mapping. Arguably this may be out of dear imgui's purpose.
• We thought about adding untranslated keycode to the io.AddKeyEvent() API but since their purpose is likely going to relate to mapping it would be problematic to have to wait until a key is pressed. Resolve we reverted to the idea that to solve this we want either a callback into the backend, into a mapping table provided by the backend.

For now we'll let this dangling as there's isn't much immediate use for this, but the branch has now been rebased over latest.

[thedmd]

Now it dangle at v1.89 (18808) :)