Support writing QOI images

[thisismypassport]

Adds support for writing .qoi files.

In more details:

• I followed the reference implementation pretty closely.
• I verified that the test files generated are the same as the reference implementation generates.
• I also followed the coding guidelines observed from the .qoi reading implementation pretty closely, and avoided touching it.

Unrelated note - the .qoi reading implementation incorrectly adds (0, 0, 0, 255) to _previously_seen_pixels at the start.
It should only be set on _previous_pixel.
However, I think this is benign since (0,0,0,255) has a different hash from (0,0,0,0) and a valid encoder won't encode (0,0,0,0) using non-0 hash values.

[radarhere]

Unrelated note - the .qoi reading implementation incorrectly adds (0, 0, 0, 255) to _previously_seen_pixels at the start.
It should only be set on _previous_pixel.

If I look at https://qoiformat.org/qoi-specification.pdf, I see

The decoder and encoder start with {r: 0, g: 0, b: 0, a: 255} as the previous pixel value.

[thisismypassport]

Unrelated note - the .qoi reading implementation incorrectly adds (0, 0, 0, 255) to _previously_seen_pixels at the start.
It should only be set on _previous_pixel.

If I look at https://qoiformat.org/qoi-specification.pdf, I see

The decoder and encoder start with {r: 0, g: 0, b: 0, a: 255} as the previous pixel value.

Yes, just as the previous pixel value - it says nothing about adding it to the hash.
And indeed, the reference implementation does not add it to the hash - neither in the encoder not decoder.

(I'll look at the other stuff a bit later today, thanks)

[radarhere]

Yes, just as the previous pixel value - it says nothing about adding it to the hash.

Ah. The part of the spec that I find most convincing is

A running array[64] (zero-initialized) of previously seen pixel values is maintained by the encoder and decoder.

I've created #9008