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

The following config was broken:
```
[mouse]
bindings = [
    { mouse = "Right", mods = "Shift", action = "Copy"            },
    { mouse = "Right", mods = "Shift", action = "ClearSelection"  },
]
```

Only the first action was applied. Change to allow more than one exact
match in mouse mode with shift held, but keep the logic to not allow
fallback search if any exact match was found.

Regression was introduced in 1a143d11.

This fixes an issue where Alacritty would crash when trying to open a
new tab on macOS while having decorations disabled.

Co-authored-by: Christian Duerr <contact@christianduerr.com>

Make `Alt` send `ESC` for unicode input the way it's done for ASCII.
Previously it was disabled because of macOS, however on macOS we're
using the `option_as_alt` setting, which solves the original issue.

The `Alt` prefixing is still disabled for the unicode strings, like
when they come from the compose input.

Fixes #7852.

On Windows some key combinations for regular text input, like Ctrl+1
don't have any text attached, so they were generating the kitty escape
sequence even when they shouldn't.

Originally kitty defined that functional keys, which are not encoded
by default, like `Pause` should be encoded with `CSI u`. However
the specification was clarified and now it says that terminal
may ignore that part. Given that Alacritty tries to follow xterm/urxvt
when it comes to bindings, CSI u bindings are not send for consistency
reasons.

This also brings back F13-F20 bindings used by Alacritty in 0.12.3, as
well as explicitly defines `NumpadEnter` like it was before.

Closes #7623.