testing needed: only use image loaders which could potentially read file

[ralfbrown]

Rather than blindly applying image loaders until one succeeds, use magic numbers at the start of the image file to determine which loader(s) to use, and apply only those. Also detect a variety of magic numbers for common non-image formats so that we don't even attempt to load them and can give an appropriately specific error to the user.

This PR will need thorough testing because it changes such a core operation. It will also have merge conflicts with #17367, which I will fix if both are accepted.

[jenshannoschwalm]

Fully agreed on this generally.

[HansBull]

I know this would render the code a little more complicated and is probably out of scope, but one could test if a jpeg file also has the 0xFFD9 end marker to determine a possible premature EOF.

[ralfbrown]

@HansBull I would expect that libJPEG reports that as corruption, but haven't actually checked into it.

[ralfbrown]

Rebased and merge conflicts fixed.

[ralfbrown]

If someone can tell my why CI keeps throwing an error (with empty log) on the "Check if it runs" step, I'll address that on the weekend.

[ralfbrown]

I was getting nowhere fast trying to trace the data flow to where temperature.c was spitting out its color matrix error message when an image file fails to load and/or aborting the pixelpipe before execution gets there, so I decided to simply suppress the message if the load failed....

[ralfbrown]

@HansBull libJPEG doesn't report corruption if the codestream for the image data proper is truncated, it just fills the missing pixels with gray. For JPEGs, showing as much of the image as is available is probably better behavior than refusing to show it at all. I haven't played around with actual file corruption other than truncation.