Refresh fuzzing corpus again following the fix of #222

[Shnatsel]

Increases edge coverage from ~1500 to ~1950. Also shrinks the corpus to 615Kb.

[HeroicKatora]

That's a good increase in coverage. We should think about how and when to do this in the future. Every changed file in the corpus is permanently part of the git history and we probably don't want to have a situation where you first download 1Gb of old fuzzing corpora on a fresh clone.

[aschampion]

What about moving the fuzzing into a separate repo tracked via a submodule (or the opposite with the png repo tracked via submodule in the fuzzer repo), so only CI and people interested in running the fuzzer have to check it out, and can usually get by with a shallow clone?

[Shnatsel]

I hoped that that such changes would be infrequent enough not to become a problem. I've re-generated the corpus following the switch to miniz_oxide and then again after I found that the fuzzing target was broken and fixed it (#222). Prior to that the fuzzing corpus was untouched for about a year. I think an extra ~2Mb of git history per year should be tolerable.

[HeroicKatora]

It's mostly the current influx that worried me, the last month. We shouldn't let this become the new norm. In particular you may want to wait for #227 which might also change the coverage by opening the possibility of fuzzing on 32-bit targets.