When the user clicks somewhere in the prompt, kitty asks the shell
to move the cursor there (since there is not much else to do).

This is currently implemented by sending an array of
forward-char-passive commands.  This has problems, for example it
is really slow on large command lines (probably because we repaint
everytime).

Implement kitty's `click_events=1` flag to set the
position directly.  To convert from terminal-coordinates
to fish-coordinates, query [CSI 6 n Report Cursor
Position](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html)
and use it to compute the left prompt's terminal-coordinates (which
are (0, 0) in fish-coordinates).

Unfortunately this doesn't work correctly while the terminal is
scrolled.  This is probably because the cursor position is wrong
if off-screen.  To fix that we could probably record the cursor
position while not scrolled, but it doesn't seem terribly important
(the existing implementation also doesn't get it right).

Also add parsing for some unused mouse events; I'll probably remove
them again unless we can use them now.

Future work:

1. Knowledge of the position of the prompt will
   also enable us to make [ctrl-l scroll instead of erasing]
   (https://codeberg.org/dnkl/foot/wiki#how-do-i-make-ctrl-l-scroll-the-content-instead-of-erasing-it)
   (as of wiki commit b57489e298f95d037fdf34da00ea60a5e8eafd6d) which
   might be a better default.

2. We still turn off mouse reporting.  If we turned it on, it
   would be harder to select text in the terminal itself (not fish).
   This would typically mean that mouse-drag will alter fish's
   selection and shift+mouse-drag or alt+mouse-drag can be used.

   To improve this, we could try to synchronize the selection:
   if parts of the fish commandline are selected in the terminal's
   selection, copy that to fish's selection and vice versa.

   Or maybe there is an intuitive criteria, like: whenever we receive
   a mouse event outside fish, turn off mouse reporting, and turn
   it back on whenver we receive new keyboard input.  One problem
   is that we lose one event (though we could send it back to the
   terminal). Another problem is we would turn it back on too late
   in some scenarios.