Fix macOS keyboard shortcut encoding

[Luflosi]

Please don't merge this yet. I need to do some cleanup and want to get some feedback first.

glfwGetCocoaKeyEquivalent() in glfw/cocoa_window.m expects the returned characters to be of type unichar, which won't work for all unicode characters because it is defined as unsigned short according to https://developer.apple.com/documentation/foundation/unichar?language=objc, which is only guaranteed to be at least 16 bits in size. The code calling this function also expects the encoding to be UTF-16.
When I added the various keys in #1928, I missed these facts. This means, that glfwGetCocoaKeyEquivalent() will behave unexpectedly when called with any of the new-ish keys. Luckily this function is currently only used for determining the macOS shortcut for new_os_window but I plan on using it more in the future.
Some of the constants, e.g. NSBackspaceCharacter are UTF-16 constants, so we can't just use UTF-8 everywhere.
I fixed the problem by using either UTF-8 characters packed into a uint32_t or UTF-16 characters in a unichar and then converting them to an NSString.
I removed the numpad keys because NSEventModifierFlagNumericPad isn't guaranteed to fit in a unichar, which makes this undefined behaviour. It also didn't work. I tried using NSEventModifierFlagNumericPad as a modifier instead, as can be seen in the first commit, but couldn't get it to work either because the constants used are native key codes and not unicode characters.

Is it ok to pass the NSString using a void pointer? Also please check if the memory for NSString is properly handled and not freed prematurely. I may need a retain or something but I still don't understand Objective-C memory management enough.

[kovidgoyal]

I'm not sure I follow. If some of the constants are UTF-16 strings, why
not simply use

unsigned short[16] cocoa_key

for the key? Or if you want to return them as UTF-8 which is a better
idea:

char[64] cocoa_key

The calling function can provide the array for it. So you dont have to
worry about memory management. I dont knwo what the limits on sizes of
key names are, so adjust the numbers above accordingly.

[Luflosi]

Shouldn't two unsigned shorts or four chars be enough, one more of each when treating it as a string with a null character at the end?
I thought about returning a UTF-8 encoded char string but then in the case where I need to return one of the UTF-16 constants, I would convert it to an NSString and call UTF8String to get the UTF-8 encoded string. But later I need the string as an NSString again, which would result in a conversion back and forth, so I chose to just directly return an NSString. I can of course still return a UTF-8 encoded char array but I think I would prefer it if I could just use an NSString.

[kovidgoyal]

Depends on what size the keynames can reach, with these sorts of things
always best to be conservative. And I dont think a glfw api should be
returning NSString, too much potential for memory issues. Either return
UTF-16 or UTF-8.

[Luflosi]

Ok, I will use UTF-8 then. But the length of the key names shouldn't matter, right? We are only returning a single Unicode character.

[kovidgoyal]

At the moment its only a single unicode character, who knows if that
will always be the case? I doubt all keys in the world use single character names.

[Luflosi]

Please review.
I made the buffer 17 bytes large to allow for at least four unicode characters, even though I can't find any keys using more than four bytes in https://github.com/xkbcommon/libxkbcommon/blob/master/xkbcommon/xkbcommon-keysyms.h.
The _glfw_strdup() will only copy the part of the string that is actually used, so we only waste memory while the function executes.

[Luflosi]

Why is making new_window_key a char array instead of dynamically allocated desirable? It wastes a tiny bit of memory over the entire runtime of kitty, the maximum size needs to be passed to the function as an extra argument, the size of the array is hardcoded in a different place from where it is written to, making it harder to find and things like if (new_window_key[0]) are a little bit harder to read than if (new_window_key) IMO. The only positive I can see is that the memory doesn't need to be free()d at the end.

[kovidgoyal]

In general it is always better to avoid library functions allocating their own
memory. Memory should be allocated and freed as close to where it is
used as possible.