A bunch of broken images, and escape hatches that "*fix*" them

[MoSal]

Hello. I've been testing a bunch of images from random sources around the internet against some JPEG decoders, and found
a bunch that fail with jpeg-decoder.

An image was considered potentially broken in my scripts if it failed with ffmpeg's -err_detect explode:

if ! ffmpeg -loglevel quiet -nostdin -err_detect explode -i "$l" -f null - &>/dev/null; then
  # ...
fi

The total number of potentially broken, but at least partially decode-able (by djpeg) images was 74, 27 of which jpeg-decoder
already decoded without error, so theoretically, the decoder needs both a stricter and a more lenient modes of operation.

The remaining images all fail currently with jpeg-decoder, 27 of which should be safe to share and are attached below:

broken_images.zip

I managed to "fix" all those images (including the non-sharable ones) with a few escape hatches, available in my fork here:
https:/MoSal/jpeg-decoder/commits/master

Those also "fix" images shared in issues around here like in #251 #229 and #228.

Details about the effects of each escape hatch on the broken images:

marker-loop-alone:
 success 9/27
 failure 18/27
without-marker-loop:
 success 0/27
 failure 27/27

without-block:
 success 13/27
 failure 14/27

without-component-fallback:
 success 27/27
 failure 0/27

without-marker-bits-read:
 success 12/27
 failure 15/27

with-all:
 success 27/27
 failure 0/27

Note that the potentially redundant component-fall-back escape hatch fixes 3 images if the following escape hatch is not applied.

[HeroicKatora]

Nice. Do you want to open this as a pull request or us to rebase changes incrementally?

[MoSal]

@HeroicKatora

I'm fine with either approach.

I didn't know if any of the changes I made are proper fixes. So this issue was just me sharing my experiments.