This commit modifies decompress_smooth_data(), adding missing MCU column
offsets to the prev_block_row and next_block_row indices that are used
for block rows other than the first and last.  Effectively, this
eliminates unexpected visual artifacts when using jpeg_crop_scanline()
along with interblock smoothing while decompressing the DC scan of a
progressive JPEG image.

Based on:
https://github.com/mo271/libjpeg-turbo/commit/0227d4fb484e6baf1565163211ee64e52e7b96bd

Fixes #456
Closes #457

This fixes a GitHub Dependabot alert regarding jquery.js.

Fixes #421

setCompDefaults() hasn't thrown an error since
aa745905 was introduced in 2.0.x.

Based on:
https://github.com/mstorsjo/libjpeg-turbo/commit/c5ef6659285a7d5bc74c679aa87ad187186cf7e1

Closes #438

Fixes #439

Closes #444

- Introduce a partial image decompression regression test script that
  validates the correctness of jpeg_skip_scanlines() and
  jpeg_crop_scanlines() for a variety of cropping regions and libjpeg
  settings.

  This regression test catches the following issues:
  #182, fixed in 5bc43c78
  #237, fixed in 6e95c086
  #244, fixed in 398c1e9a
  #441, fully fixed in this commit

  It does not catch the following issues:
  #194, fixed in 773040f9
  #244 (additional segfault), fixed in
       9120a247

- Modify the libjpeg-turbo regression test suite (make test) so that it
  checks for the issue reported in #441 (segfault in
  jpeg_skip_scanlines() when used with 4:2:0 merged upsampling/color
  conversion.)

- Fix issues in jpeg_skip_scanlines() that caused incorrect output with
  h2v2 (4:2:0) merged upsampling/color conversion.  The previous commit
  fixed the segfault reported in #441, but that was a symptom of a
  larger problem.  Because merged 4:2:0 upsampling uses a "spare row"
  buffer, it is necessary to allow the upsampler to run when skipping
  rows (fancy 4:2:0 upsampling, which uses context rows, also requires
  this.)  Otherwise, if skipping starts at an odd-numbered row, the
  output image will be incorrect.

- Throw an error if jpeg_skip_scanlines() is called with two-pass color
  quantization enabled.  With two-pass color quantization, the first
  pass occurs within jpeg_start_decompress(), so subsequent calls to
  jpeg_skip_scanlines() interfere with the multipass state and prevent
  the second pass from occurring during subsequent calls to
  jpeg_read_scanlines().

The additional segfault mentioned in #244 was due to the fact that
the merged upsamplers use a different private structure than the
non-merged upsamplers.  jpeg_skip_scanlines() was assuming the latter, so
when merged upsampling was enabled, jpeg_skip_scanlines() clobbered one
of the IDCT method pointers in the merged upsampler's private structure.

For reasons unknown, the test image in #441 did not encounter this
segfault (too small?), but it encountered an issue similar to the one
fixed in 5bc43c78, whereby it was
necessary to set up a dummy postprocessing function in
read_and_discard_scanlines() when merged upsampling was enabled.
Failing to do so caused either a segfault in merged_2v_upsample() (due
to a NULL pointer being passed to jcopy_sample_rows()) or an error
("Corrupt JPEG data: premature end of data segment"), depending on the
number of scanlines skipped and whether the first scanline skipped was
an odd- or even-numbered row.

Fixes #441
Fixes #244 (for real this time)

(again.)

Fixes #300

... on platforms that support thread-local storage.  This currently
includes all supported platforms except 32-bit macOS.

Fixes #396

This extends the fix in 1e81b0c3 to
include binary PPM files with maximum values < 255, thus preventing a
malformed binary PPM input file with those specifications from
triggering an overrun of the rescale array and potentially crashing
cjpeg, TJBench, or any program that uses the tjLoadImage() function.

Fixes #433

The jpegtran-icc test must run after the cjpeg-rgb-islow test, since
the latter generates testout_rgb_islow.jpg.

(detected with a modified version of checkstyle)

Due to an oversight, the TJCompressor.compress(int) method did not
handle YUV source images.

Fixes #413

Referring to #408, this commit #ifdefs DSPr2 SIMD functions that only
work on little endian processors, and it completely excludes
jsimd_h2v1_downsample_dspr2() and jsimd_h2v2_downsample_dspr2().  The
latter two functions fail with the TJBench tiling regression tests, most
likely because the implementation of the functions predates those tests.

If -mdspr2 is passed to the compiler, __mips_dsp will be defined, and
__mips_dsp_rev will be >= 2, so parse_proc_cpuinfo() will not be used.

Previously, these environment variables were not honored unless a 74K
CPU was detected, but this detection doesn't work properly with QEMU's
user mode emulation.  With all other CPU types, libjpeg-turbo honors
JSIMD_FORCE* regardless of CPU detection.

This CMake variable is intended to define a wrapper program for
executing cross-compiled executables.  However, CTest doesn't use
CMAKE_CROSSCOMPILING_EMULATOR, because it isn't obvious which tests
should be executed with the wrapper and which tests are scripts that
don't need it.  This commit manually prepends
${CMAKE_CROSSCOMPILING_EMULATOR} to all unit test command lines that
execute a program built by the libjpeg-turbo build system.  Thus, one
can set CMAKE_CROSSCOMPILING_EMULATOR in a CMake toolchain file to (for
instance) "qemu-{architecture} {qemu_arguments}") in order to execute
all eligible unit tests using QEMU.

(buglet)

+ document that tjFree() accepts NULL pointers without complaint.
Effectively, it has had that behavior all along, but the API does not
guarantee that tjFree() will be implemented with free() behind the
scenes, so it's best to formalize the behavior.

This programming practice (which exists in other code bases as well)
is a by-product of having used early C compilers that did not properly
handle free(NULL).  All modern compilers should properly handle that.

Fixes #398

Addresses a concern raised in #396

- Don't enumerate the types of SIMD instructions that libjpeg-turbo
  supports, as this can change without notice.
- Use more clear terminology when describing support for libjpeg v7/v8
  features ("libjpeg" is, colloquially but not officially, the name for
  the IJG's software, whereas the "libjpeg API" refers to our emulation
  of said software.)
- "PhotoShop" = "Photoshop" (StudLy Caps Police)
- Adjust dynamic library versions to reflect the addition of
  jpeg_read_icc_profile() and jpeg_write_icc_profile() in
  libjpeg-turbo 2.0.x.

insize is only used when the in-memory source manager is compiled in.

Move constants out of the .text section in simd/arm64/jsimd_neon.S and
into a .rodata section.  This ensures that the ARMv8 NEON SIMD
extensions are compatible with memory layouts that are marked
execute-only (and thus unreadable.)

Based on:
https://github.com/ivanloz/libjpeg-turbo/commit/88f3ca7664fadfb5e106efecb7845753aaf330b7

Closes #318

Homebrew tends to drop support for a macOS release the second that Apple
stops releasing security updates for it, and that makes HB difficult to
use with some of the Travis macOS images.  Furthermore, even on
supported macOS releases, HB sometimes tries to build GCC from source
even if a binary (bottle) is available.  Long story short, MacPorts just
generally has better backward compatibility.  MacPorts is also what I
personally use on the official libjpeg-turbo build machine.

... detected by ASan.  This is a similar issue to the issue that was
fixed with 402a715f.  Apparently it is
possible to create a malformed JPEG image that exceeds the Huffman
encoder's 256-byte local buffer when attempting to losslessly tranform
the image.  That makes sense, given that it was necessary to extend the
Huffman decoder's local buffer to 512 bytes in order to handle all
pathological cases (refer to 0463f7c9.)

Since this issue affected only lossless transformation, a workflow that
isn't generally exposed to arbitrary data exploits, and since the
overrun did not overflow the stack (i.e. it did not result in a segfault
or other user-visible issue, and valgrind didn't even detect it), it did
not likely pose a security risk.

Fixes #392

... that caused some JPEG images with unusual sampling factors to be
misidentified as 4:4:4.  This led to a buffer overflow when attempting
to decompress some such images using tjDecompressToYUV*().

Regression introduced by 479501b0

The correct behavior is for the TurboJPEG API to refuse to decompress
such images, which it did prior to the aforementioned commit.

Fixes #389

... when attempting to decompress grayscale JPEG images with sampling
factors != 1.

Fixes #387

... that occurred when attempting to decompress images with more than
715827882 (2048*1024*1024 / 3) pixels.

Fixes #388