ICO: Fallback to entry size when header is invalid

[RunDevelopment]

Changes;

• Error if biHeight is odd in strict mode.
• If biWidth or biHeight / 2 are zero:
  • Error in strict mode
  • Use the size specified in ICON entry as a fallback.

Integrating the fallback into the BMP decoder was a bit of a pain. I initially wanted to do in read_metadata_in_ico_format, but that doesn't work, because read_metadata (crudely) verifies that neither width nor height are zero. So the fallback logic had to be integrated more deeply.

I added 2 test images. bmp-biHeight=1.ico reproduces the bug from #3041. The only difference is that I made the 1x1 image red (black isn't a good color to check whether something decoded correctly). bmp-32bpp-biWidth=biHeight=0.ico has both width and height set to 0. Both decode fine in lenient mode and error in strict mode.

[197g]

nit: I suppose ico and bmp are tied together pretty strongly so it makes sense to see this. Just wondering if it already makes sense to have a struct of context input to the BMP that would be filled by ico instead of a non-descript u16 tuple. Your judgment call on whether that extra struct is already more mental overhead or not, a comment on the field suggesting this when future extensions pop up would also do.

[RunDevelopment]

Honestly, I was thinking of this mostly as a general modifier to how BMPs are parsed. Similar to no_file_header. I don't like the strong coupling between bmp and ico, so I tried to make something that isn't useful for ico alone. Not sure if I succeeded though...

So I'd hold the extra struct for now. If we add a second option that is exclusively used by ICO, then sure.

[RunDevelopment]

Uhm, you mostly review the ICO BMP encoder I was working on. I just messed up my commits. I'll incorporate your feedback into what I'm working on.