Fix JPEG spec references per ISO/ITU-T suggestions

- When referring to specific clauses, annexes, tables, and figures, a
  "timed reference" (a reference that includes the year) must be used in
  order to avoid confusion.
- "CCITT" = "ITU-T"
- Replace ambiguous "JPEG spec" with the specific document number.

Fix int overflow when decompr. corrupt prog. JPEG

No discernible performance regression

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9447
Credit to OSS Fuzz
Closes #259

cjpeg: Fix OOB read caused by malformed 8-bit BMP

... in which one or more of the color indices is out of range for the
number of palette entries.

Fix partly borrowed from jpeg-9c.  This commit also adopts Guido's
JERR_PPM_OUTOFRANGE enum value in lieu of our project-specific
JERR_PPM_TOOLARGE enum value.

Fixes #258

Build: Preserve CMake exe suffix from cmd line

Normally the value of CMAKE_EXECUTABLE_SUFFIX is clobbered by project().

This allows for specifying an executable suffix of .html with Emscripten
builds, which causes Emscripten to build standalone HTML versions of the
libjpeg-turbo test programs.

Honor CMake exe suffix when inst. static builds

This specifically allows an Emscripten (WASM) static build (for which
CMAKE_EXECUTABLE_SUFFIX=.js) to be properly installed.

README.ijg: Clarification regarding JPEG 2000/XR

The sentence:
"Indeed, one of the original reasons for developing this free software
was to help force convergence on common, interoperable format standards
for JPEG files."
might be seen to imply that JPEG 2000 and JPEG XR are not interoperable
with themselves, although it is certainly the case that those formats
are not interoperable with each other, nor with
ITU T.81 | ISO/IEC 10918.  They are also certainly not as common as
ITU T.81 | ISO/IEC 10918, and (as an example) popular web browsers will
not display JPEG 2000 files.

The sentence in question was originally referring to proprietary,
non-standard formats and was meant to provide historical context.
libjpeg was originally released prior to the adoption of JFIF as an
official standard, so it encouraged adoption of JFIF as a de facto
standard by providing, under a business-friendly free software license,
a library for reading and writing images in that format.

BUILDING.md: Correct iOS/Android examples

toolchain.cmake should be created in the build directory, so the scripts
need to cd to that directory before generating that file.

Closes #254

Build: Detect whether compiler supports DSPr2

This is basically the same test that was performed in acinclude.m4 in
the old autotools-based build system.  It was not ported to the
CMake-based build system because I previously had no way of testing
a non-DSPr2 build environment.

Fixes #248

Fix jpeg_skip_scanlines() segfault w/merged upsamp

Fixes NULL pointer reference when decompressing 4:2:2 or 4:2:0 JPEG
images with cinfo.do_fancy_upsampling = FALSE.

Closes #244

Fix infinite loop in partial image decompression

... caused by using certain specific combinations of
jpeg_skip_scanlines() and jpeg_read_scanlines() calls with progressive,
vertically-subsampled JPEG images.

Fixes #237

tjLoadImage(): Fix FPE triggered by malformed BMP

In rdbmp.c, it is necessary to guard against 32-bit overflow/wraparound
when allocating the row buffer, because since BMP files have 32-bit
width and height fields, the value of biWidth can be up to 4294967295.
Specifically, if biWidth is 1073741824 and cinfo->input_components = 4,
then the samplesperrow argument in alloc_sarray() would wrap around to
0, and a division by zero error would occur at line 458 in jmemmgr.c.

If biWidth is set to a higher value, then samplesperrow would wrap
around to a small number, which would likely cause a buffer overflow
(this has not been tested or verified.)

TurboJPEG: Handle JERR_BMP*,JERR_PPM* error codes

... in tjLoadImage()/tjSaveImage().  These error codes require an add-on
message table, and if it isn't initialized, then format_message()
produces "Bogus message code XXXX" instead.

Fix CVE-2018-11813

Refer to change log for details.

Fixes #242

Travis: Use SKS keyserver pool

pgp.mit.edu seems to be frequently down, which was causing the PR builds
to fail.

Additional code formatting tweaks

... detected with an improved version of our checkstyle script

Java: Further style refinements

(detected by enabling additional checkstyle modules)

This commit also removes unnecessary uses of the "private" modifier in
the Java tests/examples.  The default access modifier disallows access
outside of the package, and none of these classes is in a package.  The
only reason we use "private" with member variables in these classes is
to make checkstyle happy, because we want it to enforce that behavior in
the TurboJPEG API code.

Java: Reformat code per checkstyle recommendations

... and modify tjbench.c to match the variable name changes made to
TJBench.java

("checkstyle" = http://checkstyle.sourceforge.net, not our regex-based
checkstyle script)

TurboJPEG: Handle CMYK JPEGs w/ subsampled M, Y

Arguably it doesn't make much sense for non-chroma components to be
subsampled (which is why this type of image was overlooked in
cd7c3e6672cce3779450c6dd10d0d70b0c2278b2-- I didn't realize it was a
thing), but certain Adobe applications apparently generate these images.

Fixes #236

Bump revision to 1.5.91 for post-beta fixes

Additional code formatting tweaks

... detected with an improved version of our checkstyle script

"Further" = "Furthermore"

Grammar Police.  Has Ray Stevens taught me nothing?

x86[-64] SIMD: Don't auto-generate jsimdcfg.inc

The old Un*x (autotools-based) build system always auto-generated this
file, but that behavior was more or less a relic of the days before the
libjpeg-turbo colorspace extensions were implemented.  The thinking was
that, if a particular developer wanted to change RGB_RED, RGB_GREEN,
RGB_BLUE, or RGB_PIXELSIZE in order to compress from/decompress to
different RGB pixel layouts, then the SIMD extensions should
automatically respond to those changes whenever they were made to
jmorecfg.h.  The modern reality is that changing RGB_* is no longer
necessary because of the libjpeg-turbo colorspace extensions, and
changing any of the other constants in jsimdcfg.inc can't be done
without making deeper modifications to the SIMD extensions.  In general,
we treat RGB_* as a de facto, immutable part of the legacy libpjeg API.
Realistically, since the values of those constants have been the same in
every Un*x distribution released in the past 20-30 years, any software
that uses a system-supplied build of libjpeg must assume that those
constants will have default values.

Furthermore, even if it made sense to auto-generate jsimdcfg.inc, it was
never possible to do so on Windows, so it was always going to be
necessary to manually generate the Windows version of the file whenever
any of the constants changed.  This commit introduces a new custom CMake
target called "jsimdcfg" that can be used, on Un*x platforms, to
generate jsimdcfg.inc on demand, although this should only be necessary
when introducing new x86 SIMD instructions or making other deep
modifications, such as SIMD acceleration for 12-bit JPEGs.

For those who may be wondering why we don't do the same thing for
win/jconfig.h.in, it's because performing all of the necessary CMake
checks to populate that file is very slow on Windows.

jsimd_can_encode_mcu_AC_*(): Remove useless checks

These were necessary for the first iteration of the feature (see #46),
which provided a different C front end for the SIMD version of the
function.  The final version of the feature uses a common C front end
for both SIMD and non-SIMD implementations, so these checks are no
longer necessary.

Closes #231

Additional code formatting tweaks

... detected with an improved version of our checkstyle script

READMEs: Mention that prog JPEG is now accelerated

README.ijg: Wordsmith per ISO/ITU-T suggestions

This commit merges the following paragraph from the latest libjpeg
release:
https://github.com/libjpeg-turbo/ijg/blob/jpeg-9c/README#L222-L229
which takes into account the fact that JFIF is now an official ISO/ITU-T
standard.  I also included the ISO/IEC document number for the JFIF spec
(jpeg-9c included only the ITU-T rec number.)

This commit also heavily wordsmiths the "FILE FORMAT WARS" section.
In jpeg-7 and later, this section has become somewhat impolitic,
referring to JPEG 2000 and JPEG XR as "faulty technologies" and
"momentary mistakes."  The original intent of this section, which was
introduced in jpeg-5 and refined in jpeg-6
(https://github.com/libjpeg-turbo/ijg/blob/jpeg-5/README#L317-L338,
https://github.com/libjpeg-turbo/ijg/blob/jpeg-6b/README#L335-L367)
was to highlight the problem of JPEG file format divergence that existed
in the 1990s prior to the adoption of JFIF as an official ISO/ITU-T
standard.  That problem is fortunately no longer a problem, thanks in
part to the existence of libjpeg.  I have attempted to preserve Tom's
intent of using this section to describe which file formats the code is
compatible with and why it isn't compatible with some file formats
bearing the name "JPEG."  Such modifications always put our project in a
very awkward position, because we are not the IJG and do not claim to
be, but it is still necessary for us to modify the IJG README file from
time to time to eliminate obsolete information while attempting to
remain as neutral as possible.

Fix compiler warning w/ 32-bit MSVC builds

Fix build errors when C flags include -Werror

Instructing the compiler to treat warnings as errors caused some of the
compiler tests to fail, because the test code was not 100% clean.

Note that we now use check_symbol_exists() to check for memset() and
memcpy(), since the test code for check_function_exists() produces a
compiler warning due to not including <string.h>.

CMakeLists.txt: Move intrin.h header check

It is more readable for this to be next to the __builtin_ctzl() check,
since both are used by the accelerated progressive Huffman code.

Eliminate compiler warnings w/ Solaris Studio

PowerPC: Fix comp. warning when built w/ -maltivec

LICENSE.md: Explain why three licenses were used

jversion.h: Bump copyright year to 2018

Build: Use Colin Plumb's public domain MD5 code

... instead of the RSA code, the license for which contains an
advertising clause.  It is strongly believed that the RSA advertising
clause is innocuous, because:

- A clarification from RSA
  (http://www.ietf.org/ietf-ftp/IPR/RSA-MD-all), published in 2000,
  stated:

  "Implementations of these message-digest algorithms, including
  implementations derived from the reference C code in RFC-1319,
  RFC-1320, and RFC-1321, may be made, used, and sold without license
  from RSA for any purpose."

  Referring to the opinion from Fedora's legal team
  (https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_about_the_RSA_license_on_their_MD5_implementation.3F_Isn.27t_that_GPL-incompatible.3F),
  this means that md5.c and md5.h, which were derived from the original
  RFC 1321 reference code (http://www.faqs.org/rfcs/rfc1321.html), can
  be used without the RSA license.

- In the context of libjpeg-turbo, RSA's MD5 code was used only in the
  build/test system.  It was not part of the libjpeg-turbo binary
  distribution, and thus the only "material mentioning or referencing"
  the MD5 code was the libjpeg-turbo source code, which-- by virtue of
  including RSA's original copyright headers-- properly attributed the
  code as required under the RSA license.

However, in light of the open source community's tendency to have
knee-jerk reactions to stuff like this, it would've been necessary to
include the above explanation in our source tree in order to head off
potential FUD, and a simple fix is always better than a complex
explanation.

This commit also assigns the 3-clause BSD license to my modifications of
the MD5 code.  This license is the same one used by md5cmp and other
parts of the build system.

Travis: Deploy only when using official repo

This prevents build failures on forks that contain a master or dev
branch.

Build: Fix rpath in iOS shared libraries

When attempting to configure an iOS/ARM build with Xcode 7.2 and CMake
2.8.12, I got the following errors:

CMake Error at CMakeLists.txt:560 (add_library):
  Attempting to use MACOSX_RPATH without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG
  being set.  This could be because you are using a Mac OS X version less
  than 10.5 or because CMake's platform configuration is corrupt.
(x 3)

CMake Error at sharedlib/CMakeLists.txt:38 (add_library):
  Attempting to use MACOSX_RPATH without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG
  being set.  This could be because you are using a Mac OS X version less
  than 10.5 or because CMake's platform configuration is corrupt.
(x 3)

Upgrading to CMake 3.x (tried 3.0 and 3.1) got rid of the errors, but
the resulting shared libs still did not use @rpath as expected.  Note
also that CMake 3.x (at least the two versions I tested) does not
automatically set the MACOSX_RPATH property as claimed.  I could find
nothing in the release notes for later CMake releases to indicate that
either problem has been fixed.  What I did find was this little nugget
of code in the Darwin platform module:

https://github.com/Kitware/CMake/blob/f6b93fbf3ae00a9157af2f6497bed074d585cea9/Modules/Platform/Darwin.cmake#L33-L36

This sets CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG="-Wl,-rpath," only if you
are running OS X 10.5 or later.  It makes no such check for iOS, perhaps
because shared libraries aren't much of a thing with iOS apps.  In any
event, this commit simply sets CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG if it
isn't set already, and that fixes all of the aforementioned problems.

Travis: Don't build tags

Fix continuous integration of pull requests

- Travis doesn't set the $encrypted_* variables for PRs, so disable GPG
signing when building a PR (artifacts aren't deployed for PRs anyhow,
and even if they were, I wouldn't want them to be signed, as they may
contain unvetted code.)
- Take advantage of the new -d option in buildljt, which allows for
building from an existing Git clone directory.  This eliminates the need
to rename and restore .git/shallow, allows the official build scripts to
work properly when building PRs, and prevents 'git clone' being invoked
twice in CI builds.

Refer to #217

Include .pc and man files in MinGW install[er]s

These files are potentially useful to MinGW users, since MSYS2 MinGW
environments have a man command by default and provide an easy way to
install pkg-config.

Closes #223

release/installer.nsi.in: Remove extraneous quotes

These don't seem to affect anything, because $INSTDIR is already quoted
per 25758055ac74db8edb0486c256fe11539086498f.

jcphuff.c: Fix compiler warning

Misleading indentation, introduced by
5b177b3cab5cfb661256c1e74df160158ec6c34e

README.md: clarify where API docs can be found

ChangeLog.md: bump revision to prepare for beta

jcphuff.c: Fix compiler warning with Visual C++

GCC doesn't seem to care if we pass no arguments to the ENCODE_COEFS*
macros, but MSVC does.  Insert a no-op to make it happy.

Bump revision to 1.5.90 to prepare for beta

Label this release 2.0 instead of 1.6

This also pulls the formatting changes from
19c791cdac6df84418c66eb9d67cfa9703bc2461 into the TurboJPEG C API docs.

ChangeLog.md: clarification regarding AVX2

C/SSE2 optimization of encode_mcu_AC_first()

This commit adds C and SSE2 optimizations for the encode_mcu_AC_first()
function used in progressive Huffman encoding.

The image used for testing can be retrieved from this page:
https://blog.cloudflare.com/doubling-the-speed-of-jpegtran

All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz`
clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)`
gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0`
gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0`

Here are the results in comparison to libjpeg-turbo@293263c using
`time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg`

C
clang x86_64: +19%
gcc-5 x86_64: +80%
gcc-7 x86_64: +57%
clang i386: +5%
gcc-5 i386: +59%
gcc-7 i386: +51%

SSE2
clang x86_64: +79%
gcc-5 x86_64: +158%
gcc-7 x86_64: +122%
clang i386: +71%
gcc-5 i386: +134%
gcc-7 i386: +135%

Discussion in libjpeg-turbo/libjpeg-turbo#46

C/SSE2 optimization of encode_mcu_AC_refine()

This commit adds C and SSE2 optimizations for the encode_mcu_AC_refine()
function used in progressive Huffman encoding.

The image used for testing can be retrieved from this page:
https://blog.cloudflare.com/doubling-the-speed-of-jpegtran

All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz`
clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)`
gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0`
gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0`

Here are the results in comparison to libjpeg-turbo@3c54642 using
`time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg`

C
clang x86_64: +7%
gcc-5 x86_64: +30%
gcc-7 x86_64: +33%
clang i386: +0%
gcc-5 i386: +24%
gcc-7 i386: +23%

SSE2
clang x86_64: +42%
gcc-5 x86_64: +53%
gcc-7 x86_64: +64%
clang i386: +35%
gcc-5 i386: +46%
gcc-7 i386: +49%

Discussion in libjpeg-turbo/libjpeg-turbo#46

simd/i386/jchuff-sse2.asm: Minor formatting tweak

Format preprocessor macros more consistently

Within the libjpeg API code, it seems to be more the convention than not
to separate the macro name and value by two or more spaces, which
improves general readability.  Making this consistent across all of
libjpeg-turbo is less about my individual preferences and more about
making it easy to automatically detect variations from our chosen
formatting convention.  I intend to release the script I'm using to
validate this stuff, once it matures and stabilizes a bit.

Additional code formatting tweaks

Missed by previous analysis

Merge branch 'master' into dev

Make all get/putenv() calls compile-time optional

* Modify the SIMD dispatchers so they guard their usage of getenv() with
  the existing NO_GETENV preprocessor definition.
* Introduce a new NO_PUTENV preprocessor definition to guard the
  usage of putenv() in the TurboJPEG API library.

This at least puts Windows Store compatibility within the realm of
possibility, although further steps are required.

Win installer: allow install directories w/ spaces

Fix build with older MinGW releases

Some MinGW implementations need stdint.h in order to define SIZE_MAX.

Regression caused by a09ba29a55b9a43d346421210d94370065eeaf53 and
not fully fixed by a0047bdea4d11dfeefb9ea797865b1a2ea0a665e.

Closes #220

turbojpeg.c: Fix Windows build

Broken by previous commit.  Although turbojpeg.c no longer needs
tjutil.h on Un*x, it still needs to include that file on Windows in
order to use snprintf() and strcasecmp() (which, on Windows, are macros
that wrap _snprintf_s() and stricmp().)

Merge branch 'master' into dev

Improve code formatting consistency

With rare exceptions ...
- Always separate line continuation characters by one space from
  preceding code.
- Always use two-space indentation.  Never use tabs.
- Always use K&R-style conditional blocks.
- Always surround operators with spaces, except in raw assembly code.
- Always put a space after, but not before, a comma.
- Never put a space between type casts and variables/function calls.
- Never put a space between the function name and the argument list in
  function declarations and prototypes.
- Always surround braces ('{' and '}') with spaces.
- Always surround statements (if, for, else, catch, while, do, switch)
  with spaces.
- Always attach pointer symbols ('*' and '**') to the variable or
  function name.
- Always precede pointer symbols ('*' and '**') by a space in type
  casts.
- Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG
  API libraries (using min() from tjutil.h is still necessary for
  TJBench.)
- Where it makes sense (particularly in the TurboJPEG code), put a blank
  line after variable declaration blocks.
- Always separate statements in one-liners by two spaces.

The purpose of this was to ease maintenance on my part and also to make
it easier for contributors to figure out how to format patch
submissions.  This was admittedly confusing (even to me sometimes) when
we had 3 or 4 different style conventions in the same source tree.  The
new convention is more consistent with the formatting of other OSS code
bases.

This commit corrects deviations from the chosen formatting style in the
libjpeg API code and reformats the TurboJPEG API code such that it
conforms to the same standard.

NOTES:
- Although it is no longer necessary for the function name in function
  declarations to begin in Column 1 (this was historically necessary
  because of the ansi2knr utility, which allowed libjpeg to be built
  with non-ANSI compilers), we retain that formatting for the libjpeg
  code because it improves readability when using libjpeg's function
  attribute macros (GLOBAL(), etc.)
- This reformatting project was accomplished with the help of AStyle and
  Uncrustify, although neither was completely up to the task, and thus
  a great deal of manual tweaking was required.  Note to developers of
  code formatting utilities:  the libjpeg-turbo code base is an
  excellent test bed, because AFAICT, it breaks every single one of the
  utilities that are currently available.
- The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been
  formatted to match the SSE2 code (refer to
  ff5685d5344273df321eb63a005eaae19d2496e3.)  I hadn't intended to
  bother with this, but the Loongson MMI implementation demonstrated
  that there is still academic value to the MMX implementation, as an
  algorithmic model for other 64-bit vector implementations.  Thus, it
  is desirable to improve its readability in the same manner as that of
  the SSE2 implementation.

usage.txt: Remove Alt-Space non-ASCII character

Fix build when RGB_{RED,GREEN,BLUE}!={0,1,2}

Broken by aa7459050d7a50e1d8a99488902d41fbc118a50f

Travis: OS X official builds now use YASM

Because 367a838626576b4ff2a47cbd5a494199b800dc48

Loongson MMI SIMD extensions

Based on:
https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8

Closes #158

SIMD: Formatting tweaks + remove unnecessary code

+ "JSIMD_ARM_NEON" = "JSIMD_NEON"
+ "JSIMD_MIPS_DSPR2" = "JSIMD_DSPR2"
+ "*_mips_dspr2" = "*_dspr2"

It's obvious that "NEON" refers to Arm and "DSPr2" refers to MIPS, and
this naming convention is consistent with the other SIMD extensions.

Fix iOS/ARM[-64] build w/ newer versions of CMake

Newer versions of CMake (known to be the case with 3.7.x and 3.10.x)
fail to add a space between CMAKE_C_FLAGS and CMAKE_ASM_FLAGS, which
causes the build to fail when using the official build procedure.

Closes #216

Make SIMD syms private for x86[-64]/Mach-O builds

... if building with YASM.  NASM doesn't currently support the necessary
directives.

Closes #212

Merge branch 'master' into dev

Closes #214

Fix Win64 ABI conformance when using xmm8-xmm11

Referring to https://docs.microsoft.com/en-US/cpp/build/stack-usage:

"All memory beyond the current address of RSP is considered volatile:
The OS, or a debugger, may overwrite this memory during a user debug
session, or an interrupt handler.  Thus, RSP must always be set before
attempting to read or write values to a stack frame."

Basically, if-- under extremely rare circumstances-- a context swap were
to occur between saving the values of xmm8-xmm11 and setting the new
value of rsp, the O/S might not preserve that area of the stack.  In
general, libjpeg-turbo should not be using xmm8-xmm11 before or after
the call to jsimd_huff_encode_one_block_sse2(), so this is probably a
non-issue, but it's still a good idea to fix it.

Based on
https://github.com/mayeut/libjpeg-turbo/commit/ff7d2030dd26c7b8c37ff540c594490198843f15

Fix BUILDING.md buglet ("--mfloat-abi=softfp")

(Introduced with the build system overhaul)

Closes #215

Fix Win64 ABI conformance issue in AVX2 ISLOW IDCT

xmm8-xmm11 must be saved and restored, since the function uses
ymm8-ymm11.

Closes #211

Fix build with YASM

vinserti128 requires all operands to be specified

Make SIMD symbols private for MIPS ELF builds

Closes #210

Make SIMD symbols private for iOS ARM/ARM64 builds

Make SIMD symbols private for x86[-64] ELF builds

32-bit AVX2 implementation of slow int inverse DCT

32-bit AVX2 buglet: IS_ALIGNED_SSE=IS_ALIGNED_AVX

64-bit AVX2 implementation of slow int inverse DCT

32-bit AVX2 implementation of int sample conv.

32-bit AVX2 implementation of slow int forward DCT

64-bit AVX2 implementation of int sample conv.

64-bit AVX2 implementation of slow int forward DCT

AVX2: Introduce YMMBLOCK macro for readability

Prog Huff enc: bit count/branchless abs val opts

Ported from baseline Huffman encoder.  This improves overall compression
performance by ~3-9% in my testing.

Merge branch 'master' into dev

README.md: Fix permissions

Merge branch 'master' into dev

Fix dithering bug in merged 4:2:0/RGB565 algorithm

d0 should always be used for the first row, and d1 should always be used
for the second row.

Addresses concerns raised in #95, #81.

Merge branch 'master' into dev

Travis/OS X: Use 'brew bundle' + Brewfile

This ensures that the build script will not fail if the Homebrew
dependencies are already installed.

Merge branch 'master' into dev

jdarith.c: Fix two signed integer overflows

I guess I have to fix these, or Google Autofuzz is going to keep bugging
me about them.

Fixes #171
Fixes #197
Fixes #198

Bump version to 1.5.4 to prepare for new commits

BUILDING.md: Adjust Android recipes for NDK r16+

NDK r16b moved some things around, so modify the Android build recipes
to take that into account while preserving compatibility with previous
NDK releases.

NOTE: the GCC 4.9 NDK toolchain is deprecated, so we will need to
develop new Android build recipes for libjpeg-turbo 1.6 that use the
Clang toolchain.

Closes #196

Fix whitespace errors

Merge branch 'master' into dev

+ acknowledge 1.5.3 release

jpeg_crop_scanlines: Handle gray images w/ samp!=1

Since the sampling factor has no meaning for single-component images,
the decompressor ignores it, and jpeg_crop_scanlines() should as well.

Fixes #195

Fix lib state when skipping to end of 1-scan image

If jpeg_skip_scanlines() is used to skip to the end of a single-scan
image, then we need to change the library state such that subsequent
calls to jpeg_consume_input() will return JPEG_REACHED_EOI rather than
JPEG_SUSPENDED.  (NOTE: not necessary for multi-scan images, since the
scans are processed prior to any call to jpeg_skip_scanlines().)

Unless I miss my guess, using jpeg_skip_scanlines() in this manner
will prevent any markers at the end of the JPEG image from being
read, but I don't think there is any way around that without actually
reading the data, which would defeat the purpose of
jpeg_skip_scanlines().

Fixes #194

Merge branch 'master' into dev

Travis: Work around xcode7.3 image bug

Refer to travis-ci/travis-ci#8552.  This was supposed to be fixed on
November 15, then on November 28.  Travis blew through both deadlines,
so I have no confidence that the issue will be fixed as promised in a
timely manner.  Adding 'brew update' to .travis.yml slows the OS X
build, but there is no choice at the moment.

tjLoadImage(): Fix OOB array access w/TJPF_UNKNOWN

Because the previous commit added a test for TJPF_UNKNOWN to tjunittest,
the ASAN CI build detected this issue.