Fix Kitty protocol reporting shifted keycodes

The [kitty keyboard protocol][1] explicitly requires that the
*un-shifted* version of the pressed key is used to report the primary
code point in `CSI code-point;modifiers u` sequences.

> Note that the codepoint used is always the lower-case (or more
> technically, un-shifted) version of the key. If the user presses, for
> example, ctrl+shift+a the escape code would be CSI 97;modifiers u. It
> must not be CSI 65; modifiers u.

Alacritty's current behavior is to report the shifted version when shift
is pressed, and the un-shifted version otherwise:

```console
 # Note that you'll have to kill Alacritty after running this to get
 # control back!
$ echo -ne '\x1b[>1u'; cat
^[[97;5u^[[65;6u
```

The above was generated by pressing `CTRL`+`a` followed by
`CTRL`+`SHIFT`+`a` after running the command. Here `97` and `65` are the
codepoints for `a` and `A` respectively.

This change makes Alacritty match the protocol (and Kitty's) behavior.
With this change applied, `97` is reported for both `CTRL`+`a` and
`CTRL`+`SHIFT`+`a`.

[1]: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#key-codes

CHANGELOG.md

@@ -26,6 +26,7 @@ Notable changes to the `alacritty_terminal` crate are documented in its
   had multiple actions only performed the first action
 - Leaking FDs when closing windows on Unix systems
 - Config emitting errors for non-existent import paths
+- Kitty keyboard protocol reporting shifted key codes
 
 ## 0.13.2
 

alacritty/src/input/keyboard.rs

@@ -373,7 +373,7 @@ impl SequenceBuilder {
             {
                 format!("{unicode_key_code}:{alternate_key_code}")
             } else {
-                alternate_key_code.to_string()
+                unicode_key_code.to_string()
             };
 
             Some(SequenceBase::new(payload.into(), SequenceTerminator::Kitty))