Would you like a very simple jpegcheck script?

I think it would be good to have a simple `jpegcheck` script, given the "-archive" in the name of this project. Would you like me to send one?

```
find "$@" \( -iname '*.jpg' -o -iname "*.jpeg" \) -print0 |
parallel -0 -m jpeginfo --check 2>&1 |
grep -v '\[OK\]$'
```

## motivation

The intent is to flag up if jpegs start suffering obvious corruption from storage faults or crashes. You can scan for bad jpegs on your online storage, before you overwrite the old backup that has the old non-corrupted version of the file 8-). And of course backups *should* include strong checksums, but users may also have created replicas by simple file copy. Sadly, filesystems which do checksums for you automatically are still not a commodity, and dm-integrity has a significant performance cost.

## technical limitations

I can unify the above to best match the style / behaviour of `jpeg-archive`. However, I plan not to return a different exit code on failures. AFAICT *Ladon* does not change exit code on failures, even if you pass `--fail` (which I don't want anyway; I want to show *all* jpegs which have warnings).

Also it doesn't like newlines in filenames / paths. If you include newlines in filenames, you are being horrible and my `jpegcheck` will probably tell you there is some error by cryptically printing the first line of `jpeginfo --check` output.

## why `jpeginfo --check`

I used to use a fancier script but this works well for JPGs. `jpeginfo --check` is [often recommended](https://stackoverflow.com/questions/2974311/how-do-i-check-if-all-files-inside-directories-are-valid-jpegs-linux-sh-script). It certainly seems to be *fast* compared the alternatives. And at least it seems more appropriate than relying on an undocumented implementation detail of the `-verbose` flag to `identify`!

So far I haven't seen it miss any case that `djpeg -fast -grayscale -onepass` would have picked up (and that command is maybe 33% slower and only accepts one image at a time). I have searched for reports complaining that jpeginfo overlooks some error, and not found anything.

Start by comparing the proposed find/parallel/jpeginfo pipeline with the existing jpeg-archive command-line style and behavior. Confirm how a new script would be added and invoked, then verify that it reports all JPEG warnings without changing its exit-code behavior; no repository file or test is named in the issue.

Written by the indexing model from the issue text.