This commit changes a LOT of areas of the code to use decl literals instead of redundantly referring to the type. These changes were mostly driven by some regex searches and then manual adjustment on a case-by-case basis. I almost certainly missed quite a few places where decl literals could be used, but this is a good first step in converting things, and other instances can be addressed when they're discovered. I tested GLFW+Metal and building the framework on macOS and tested a GTK build on Linux, so I'm 99% sure I didn't introduce any syntax errors or other problems with this. (fingers crossed)
Fixes #7337 AppKit encodes functional keys as PUA codepoints. We don't want to send that down as valid text encoding for a key event because KKP uses that in particular to change the encoding with associated text. I think there may be a more specific solution to this by only doing this within the KKP encoding part of KeyEncoder but that was filled with edge cases and I didn't want to risk breaking anything else.
Fixes a regression where `ctrl+enter` was not encoding properly since our input stack changes.
This applies the same logic from #1659 to Kitty encoding.
Fixes #5929 Replaces #5984 On macOS, native applications typically never encode any text for key events that use the command key. This is because the command key is used for key equivalents and "commands" and should not be used for text input. This can be verified with apps like TextEdit but also terminals like Terminal.app officially but also iTerm2 unofficially. Anything such as `Cmd+b` or `Cmd+Shift+b` will not produce any text input. Cross-platform terminals generally don't follow this, for example Kitty performs CSI-u encoding and Alacritty and WezTerm encode the text as-is (i.e. `Cmd+b` will produce `b`). On Linux, the super key (command-equivalent) does produce text input. For example, `Super+b` will produce `b` in Gnome Console, Foot, and all the cross-platform terminals mentioned above. In the interest of matching the behavior of native macOS applications, we should not encode text for command key events on macOS. We continue to encode text for the super key on non-macOS platforms.