take advantage of kitty keyboard protocol

[dankamongmen]

I thought i had a bug on this, but i guess not? https://sw.kovidgoyal.net/kitty/keyboard-protocol/ seems a reasonable thing to support. it would have a few parts:

• move to the alternate screen before doing queries
• lex the kitty protocol elements
• query for support with CSI ? u
• watch for support response of form CSI ? flags u
• request stepup with CSI = flags ; 1 u
• push the current keyboard handling state at startup with CSI > u
• pop the keyboard handling state at exit with CSI < u
• synthesize SIGINT and SIGQUIT

so throw the query into our initial query string. initialize keyflags to 0. if we get a CSI ? flags u response, write flags to keyflags, and emit stepup CSI = flags ; 1 u and push CSI > u.

decode the inputs regardless of what flags said.

at exit, if we pushed, pop with CSI < u.

[dankamongmen]

looks like the kitty keyboard protocol disables the standard line discipline:

With this flag turned on, all key events that do not generate text are represented in one of the following two forms:
CSI number; modifier u
CSI 1; modifier [~ABCDEFHPQRS]
This makes it very easy to parse key events in an application. In particular, ctrl+c will no longer generate the SIGINT signal, but instead be delivered as a CSI u escape code.

[dankamongmen]

i've started the dankamongmen/kitty-keyboard branch for this.

[dankamongmen]

looks like we also need to make the switch to the alternate screen (if we intend to do it) before sending any of this, as the keyboard context is per-screen. added another item.

[dankamongmen]

looks like there's some limited support for this using XTMODKEYS, of which i was unaware.

[dankamongmen]

yeah we definitely need to move our push and set after smcup; this is why we remain in markedup mode following exit from notcurses-input currently.