New design:
* capture output to a vstr
* compare the complete vstr to boot_out.txt
* rewrite if not a complete match
This is resilient against future changes to the automatic
text written to boot_out.txt.
This also fixes rewriting boot_out.txt in the case where
boot.py prints something.
Perhaps it also saves a bit of code space. Some tricks:
* no need to close a file in read mode
* no need to switch on/off USB write access, going down to the
oofatfs layer doesn't check it anyway
The easiest thing to implement was to use the i/j numbers, but they were not
directly related to image x/y coordinates. This may slow things down a tiny
little bit, but it looks much better.
* Increase colorspace conversion efficiency.
This not only avoids a function call, it avoids the time-consuming
switch statement in conver_pixel (replacing it with a single
conditional on the byteswap flag + accounting for BGR/RGB during
palette creation)
* Buffer all the bytes of a single frame together. By reducing
low level write calls we get a decent speed increase even though
it increases data-shuffling a bit.
Together with some other changes that enable "double buffered" camera
capture, this gets me to 8.8fps capturing QVGA (320x240) gifs and
11fps capturing 240x240 square gifs.
This involves:
* Adding a new "L8" colorspace for colorconverters
* factoring out displayio_colorconverter_convert_pixel
* Making a minimal "colorspace only" version of displayio for the
unix port (testing purposes)
* fixing an error message
I only tested writing B&W animated images, with the following script:
```python
import displayio
import gifio
with gifio.GifWriter("foo.gif", 64, 64, displayio.Colorspace.L8) as g:
for i in range(0, 256, 14):
data = bytes([i, 255-i] * 32 + [255-i, i] * 32) * 32
print("add_frame")
g.add_frame(data)
# expected to raise an error, buffer is not big enough
with gifio.GifWriter("/dev/null", 64, 64, displayio.Colorspace.L8) as g:
g.add_frame(bytes([3,3,3]))
```
