Fix extended scancode of 0 not being processed correctly

On Windows, keyboard events with an extended 0 Windows scancode are now
processed by mapping the virtual-key code to a Windows scancode using
the Win32 MapVirtualKey function.

Some keyboard scancodes (in particular, ones used for some non-typical
keys) are not mapped to corresponding Windows scancodes, and are instead
mapped to an extended 0 Windows scancode, with the distinction being
only in the virtual-key code.

This causes GLFW to report a 256 GLFW scancode (0x00 | 0x100, 0x100
being the extended bit bitmask) for any of those keys, which causes API
consumers to be unable to distinguish between them.

There exists, however, a Win32 function MapVirtualKey that maps those
virtual key-codes to proper Windows scancodes. GLFW even appears to use
this workaround, but after further inspection, it checks whether the
Windows scancode is 0 (0x00), and not extended 0 (0x100).

This change makes GLFW check for the extended 0 keycode instead, which
seems to work correctly. I'm not sure if checking for the non-extended 0
Windows scancode was intentional, as I never seem to have encountered
one during testing with multiple keyboards. Thus, the handling of the
non-extended 0 Windows scancode was removed, but it can be brought back
if necessary.

CONTRIBUTORS.md

@@ -263,6 +263,7 @@ video tutorials.
  - Jonas Ådahl
  - Lasse Öörni
  - Leonard König
+ - Grzesiek11
  - All the unmentioned and anonymous contributors in the GLFW community, for bug
    reports, patches, feedback, testing and encouragement
 

README.md

@@ -229,6 +229,7 @@ information on what to include when reporting a bug.
  - [Win32] Bugfix: Instance-local operations used executable instance (#469,#1296,#1395)
  - [Win32] Bugfix: The OSMesa library was not unloaded on termination
  - [Win32] Bugfix: Right shift emitted `GLFW_KEY_UNKNOWN` when using a CJK IME (#2050)
+ - [Win32] Bugfix: Extended scancode of 0 was not being processed correctly
  - [Cocoa] Added support for `VK_EXT_metal_surface` (#1619)
  - [Cocoa] Added locating the Vulkan loader at runtime in an application bundle
  - [Cocoa] Moved main menu creation to GLFW initialization time (#1649)

src/win32_window.c

@@ -710,11 +710,11 @@ static LRESULT CALLBACK windowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM l
             const int mods = getKeyMods();
 
             scancode = (HIWORD(lParam) & (KF_EXTENDED | 0xff));
-            if (!scancode)
+            if (scancode == 0x100)
             {
-                // NOTE: Some synthetic key messages have a scancode of zero
+                // NOTE: Some synthetic key messages have a scancode of extended zero
                 // HACK: Map the virtual key back to a usable scancode
-                scancode = MapVirtualKeyW((UINT) wParam, MAPVK_VK_TO_VSC);
+                scancode = KF_EXTENDED | MapVirtualKeyW((UINT) wParam, MAPVK_VK_TO_VSC);
             }
 
             // HACK: Alt+PrtSc has a different scancode than just PrtSc