This sort of command is treated as valid by Kitty so we should too. In
fact, it occurs with the example `send-png` script provided in the docs
for the protocol.
This commit increases the value buffer to 11 characters - this is
technically what it should be to allow for large negative integers
(i.e., 2.4 billion plus the sign character).
Additionally corrected the types for 'H' (horizontal offset) and 'V'
(vertical offset) - these are supposed to be i32 versus u32.
Added some extra tests to test all of this stuff as well.
I've also added a few more tests to help track these cases.
Fixes#2190
The `q` value with chunk transmissions is a bit complicated. The initial
transmission ("start" command) `q` value is used for all subsequent
chunks UNLESS a subsequent chunk specifies a `q >= 1`. If a chunk
specifies `q >= 1`, then that `q` value is subsequently used for all
future chunks unless another chunk specifies `q >= 1`. And so on.
This commit importantly also introduces the ability to test a full Kitty
command from string request to structured response. This will let us
prevent regressions in the future and ensure that we are correctly
handling the complex underspecified behavior of Kitty Graphics.
If the transmission medium is a local-only medium, ignore the "m"
key. The Kitty graphics protocol specification does not explicitly
call out this behavior (although the "m" key is only mentioned in
connection with remote clients) but that's how it's implemented in
Kitty and at least one client (mpv) relies on this behavior when
using the shared memory transmission medium.
https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-transmission-mediumccc3bee9af/kitty/graphics.c (L547-L592)
The shared memory segment size must be a multiple of page size. This
means that it may be larger than our expected image size. In this case,
we trim the padding at the end.
