Microsoft documentation says:
> If biCompression equals BI_RGB and the bitmap uses 8 bpp or less, the bitmap has a color table immediatelly following the BITMAPINFOHEADER structure. The color table consists of an array of RGBQUAD values. The size of the array is given by the biClrUsed member. If biClrUsed is zero, the array contains the maximum number of colors for the given bitdepth; that is, 2^biBitCount colors.
Formerly, we treated 0 colors as "no image palette" during construction,
but then during common_hal_displayio_ondiskbitmap_get_pixel indexed into
the palette anyway. This could have unpredictable results. On a pygamer,
it gave an image that was blue and black. On magtag, it gave a crash.
The transparent_color field was never initialized. I _think_ this means
its value was always set to 0, or the blackest of blacks. Instead,
initialize it to the sentinel value, newly given the name
NO_TRANSPARENT_COLOR.
This exposed a second problem: The test for whether there was an existing
transparent color was wrong (backwards). I am guessing that this was not
found due to the first bug; since the converter had a transparent color,
the correct test would have led to always getting the error "Only one
color can be transparent at a time".
Closes#3723
This resolves the build error
```
arm-none-eabi-ld: build-spresense/libmpy.a(Camera.o):(.rodata.camera_imageformat_type+0x0): multiple definition of `camera_imageformat_type'; build-spresense/libmpy.a(__init__.o):(.rodata.camera_imageformat_type+0x0): first defined here
arm-none-eabi-ld: build-spresense/libmpy.a(ImageFormat.o):(.rodata.camera_imageformat_type+0x0): multiple definition of `camera_imageformat_type'; build-spresense/libmpy.a(__init__.o):(.rodata.camera_imageformat_type+0x0): first defined here
arm-none-eabi-ld: build-spresense/libmpy.a(Camera.o):(.rodata.camera_imageformat_type+0x0): multiple definition of `camera_imageformat_type'; build-spresense/libmpy.a(__init__.o):(.rodata.camera_imageformat_type+0x0): first defined here
```
