BUILDING.md: Fix "... OR ..." indentation again

<sigh> GitHub doesn't render indented text the same as my local MarkDown
viewer (MacDown), so it's necessary to indent "... OR ..." by 3 spaces
so both will display it on the same indentation level as "Visual C++
2005 or later" and "MinGW".

BUILDING.md: Fix confusing Windows build reqs

Indent "... OR ..." to make it clear that the choice is between Visual
C++ and MinGW, not Visual C++ and MinGW + NASM.  Move NASM to the top of
the list to make that even more clear.  Make it clear that nasm.exe
should be in the PATH.

Addresses concerns raised in #70

Merge branch '1.4.x'

cjpeg: Fix buf overrun caused by bad bin PPM input

This extends the fix in 6709e4a0cfa44d4f54ee8ad05753d4aa9260cb91 to
include binary PPM/PGM files, thus preventing a malformed binary
PPM/PGM input file from triggering an overrun of the rescale array and
potentially crashing cjpeg.

Note that this issue affected only cjpeg and not the underlying
libjpeg-turbo libraries, and thus it did not represent a security
threat.

Thanks to @hughdavenport for the discovery.

Merge branch '1.4.x'

Add version/build info to global string table

This is a common practice in other infrastructure libraries, such as
OpenSSL and libpng, because it makes it easy to examine an application
binary and determine which version of the library the application was
linked against.

Closes #66

ChangeLog.md: Improve readability of plain text

change.log: Refer users to ChangeLog.md

change.log is included only to document the changes that we have merged
from libjpeg.

Markdown version of ChangeLog.txt

This will make it easier to crib ChangeLog information into release
notes, since both SourceForge and GitHub support MD.

Rename ChangeLog.txt

... in preparation for creating a MarkDown version (Git will not
preserve history unless you rename the file prior to modifying it.)

README.md: Link to BUILDING.md

Addresses a concern expressed in #56 and #58.

BUILDING.md and README.md: Cosmetic tweaks

ChangeLog: "1.5 beta1" --> "1.4.90 (1.5 beta1)"

(for consistency with other beta release headings)

Merge branch '1.4.x'

Ensure that default Huffman tables are initialized

This prevents a malformed motion-JPEG frame (MJPEG frames lack Huffman
tables) from causing the "fast path" of the Huffman decoder to read
uninitialized memory.  Essentially, this is doing the same thing for
MJPEG frames as 43d8cf4d4572fa50a37cccadbe71b9bee37de55d did for regular
images.

Java: Fix parallel make with autotools

Running 'make -j{jobs}' on a build that was configured with Java
(--with-java) would previously cause an error:

    make: *** No rule to make target `TJExample.class', needed by
        `turbojpeg.jar'.

It seems that parallel make doesn't understand that the files in
$(JAVA_CLASSES) are all generated from the same invocation of javac, so
it tries to parallelize the building of those files (which of course
doesn't work.)  This patch instead makes turbojpeg.jar depend on
classnoinst.stamp.  This effectively creates a synchronization fence,
since that file is only created when all of the class files have been
built.

Fixes #62

Win/x64: Fix improper callee save of xmm8-xmm11

The x86-64 SIMD accelerations for Huffman encoding used incorrect
stack math to save xmm8-xmm11 on Windows.  This caused TJBench to
always report 1 Mpixel/sec for the compression performance, and it
likely would have caused other application issues as well.

Bump TurboJPEG C API revision to 1.5

The changes relative to 1.4.x are only cosmetic (using const pointers)
and should not affect API/ABI compatibility, but our practice is to
synchronize the API revision with the most recent release that provides
user-visible changes to the API.

ChangeLog: Mention jpeg_crop_scanline() function

1.5 beta1

Merge branch '1.4.x'

Fix memory leak when running tjunittest -yuv

Closes #61

Fix v7/v8-compatible build

Broken by 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e

Fixes #60

libjpeg API: Partial scanline decompression

This, in combination with the existing jpeg_skip_scanlines() function,
provides the ability to crop the image both horizontally and vertically
while decompressing (certain restrictions apply-- see libjpeg.txt.)

This also cleans up the documentation of the line skipping feature and
removes the "strip decompression" feature from djpeg, since the new
cropping feature is a superset of it.

Refer to #34 for discussion.

Closes #34

Build: Make the NASM autoconf variable persistent

Previously, if a custom value of this variable was specified when
running configure, then that value would be lost if configure was
automatically re-run (as a result of changes to configure.ac, for
instance.)

As a bonus, the NASM variable is now also listed when running
'configure --help', so it is obvious how to override the default
NASM command.

Use consistent/modern code formatting for dbl ptrs

usage.txt: Restore accidentally deleted phrase

It somehow got lost when merging the jpeg-9+ documentation changes.

More minor code formatting tweaks

Clean up a couple of copyright messages

Use consistent/modern code formatting for pointers

The convention used by libjpeg:

    type * variable;

is not very common anymore, because it looks too much like
multiplication.  Some (particularly C++ programmers) prefer to tuck the
pointer symbol against the type:

    type* variable;

to emphasize that a pointer to a type is effectively a new type.
However, this can also be confusing, since defining multiple variables
on the same line would not work properly:

    type* variable1, variable2;  /* Only variable1 is actually a
                                    pointer. */

This commit reformats the entirety of the libjpeg-turbo code base so
that it uses the same code formatting convention for pointers that the
TurboJPEG API code uses:

    type *variable1, *variable2;

This seems to be the most common convention among C programmers, and
it is the convention used by other codec libraries, such as libpng and
libtiff.

Reorder copyright messages in cjpeg/djpeg/jpegtran

Place the authors in the following order:
* libjpeg-turbo authors (2009-) in descending order of the date of their
  most recent contribution to the project, then in ascending order of
  the date of their first contribution to the project
* Upstream authors in descending order of the date of the first
  inclusion of their code (this indicates that their code serves as the
  foundation of this code.)

This also adds Siarhei to the author list, since he contributed ARM SIMD
code both as a Nokia employee and more recently as an independent
developer.

Include some comments/doc tweaks from jpeg-9+

Wordsmith GIF limitations in cjpeg.1/djpeg.1

The Independent JPEG Group's JPEG software v9b

The Independent JPEG Group's JPEG software v9a

The Independent JPEG Group's JPEG software v9

Clean up pkgconfig dir when removing RPM & Mac pkg

Fix compiler warning

Win: Display effective C/LD flags in CMake output

Java: Avoid OOM error when running 'make test'

We need to garbage collect between iterations of the outside loop in
bufSizeTest() in order to avoid exhausting the heap when running with
Java 6 (which is still used on Linux to test the 32-bit version of
libjpeg-turbo in automated builds.)

ARM64: Avoid tbl instruction on Cortex-A53/A57

Full-color compression speedups relative to previous commits:
Cortex-A53 (Nexus 5X), Android, 64-bit: 0.91-3.0% (avg. 1.8%)
Cortex-A57 (Nexus 5X), Android, 64-bit: -0.35-1.5% (avg. 0.65%)

ChangeLog: Mention ARM64 Huffman & adj perf claims

Fix iOS/ARMv8 build

Broken by 46ecffa324be43aab80f6160dc57d98b0a54a704.

gas-preprocessor.pl and/or the clang assembler apparently don't like
default values in macro arguments, and we need to use a separate const
section for each function (because of our use of adr, also necessitated
by the broken clang assembler.)

BUILDING.md: Update OS X Java information

The Apple Java Developer Package is only necessary on OS X < 10.7.
When building on Lion and later, the Oracle JDK is preferred.

Fix 'make dist'; Include LICENSE.md in packages

ARM64: Avoid LD3/ST3 at run time, not compile time

... and only if ThunderX is detected.  This can be easily expanded later
on to include other CPUs that are known to suffer from slow LD3/ST3, but
it doesn't make sense to disable LD3/ST3 for all non-Android Linux
platforms just because ThunderX is slow.

ARM64 NEON SIMD implementation of Huffman encoding

Full-color compression speedups relative to previous commits:
Cortex-A53 (Nexus 5X), Android, 64-bit: 1.1-13% (avg. 6.0%)
Cortex-A57 (Nexus 5X), Android, 64-bit: 0.0-22% (avg. 6.3%)

Refer to #47 and #50 for discussion

Closes #50

Note that this commit introduces a similar /proc/cpuinfo parser to that
of the ARM32 implementation.  It is used to specifically check whether
the code is running on Cavium ThunderX and, if so, disable the ARM64
SIMD Huffman routines (which slow performance by an average of 8% on
that CPU.)

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

ARM SIMD: Comment tweaks

Un*x: Enable testing cross-compiled builds

Don't include the all: target as a dependency of the tests when
cross-compiling, and ensure that the files generated by the tests are
removed, even if they were created read-only (or if the tests are being
run on a different type of system that doesn't correctly interpret the
file permissions.)  This allows one to easily build the code on one
machine and run 'make test' on another.

Fix Visual C++ compiler warnings

Somehow this got reverted with aa769febf25c64f115c2a237516b0c7d65f651cd.
Oops.

Win: Enable testing cross-compiled builds

When cross-compiling, CMakeLists.txt now generates the CTest script
using relative paths, so that CTest can more easily be executed on a
different machine from the build machine.  Furthermore, Windows builds
are now tested using md5cmp, just like on Linux, rather than a CMake
script.  This prevents issues with differing CMake locations between
the build and test machines.

This also removes some trailing spaces from the md5cmp code and improves
the readability of the test code in CMakeLists.txt.

Fix MinGW build

jinclude.h can't be safely included multiple times, so instead of
including it in the shared (broken-out) headers, it should instead be
included by the source files that include one or more of those headers.

Update MinGW Linux build recipe

Merge branch '1.4.x'

Merge branch '1.3.x' into 1.4.x

Merge branch '1.2.x' into 1.3.x

Prevent overread when decoding malformed JPEG

The accelerated Huffman decoder was previously invoked if there were
> 128 bytes in the input buffer.  However, it is possible to construct a
JPEG image with Huffman blocks > 430 bytes in length
(http://stackoverflow.com/questions/2734678/jpeg-calculating-max-size).
While such images are pathological and could never be created by a
JPEG compressor, it is conceivable that an attacker could use such an
artifially-constructed image to trigger an input buffer overrun in the
libjpeg-turbo decompressor and thus gain access to some of the data on
the calling program's heap.

This patch simply increases the minimum buffer size for the accelerated
Huffman decoder to 512 bytes, which should (hopefully) accommodate any
possible input.

This addresses a major issue (LJT-01-005) identified in a security audit
by Cure53.

Guard against wrap-around in alloc functions

Because of the exposed nature of the libjpeg API, alloc_small() and
alloc_large() can potentially be called by external code.  If an
application were to call either of those functions with
sizeofobject > SIZE_MAX - ALIGN_SIZE - 1, then the math in
round_up_pow2() would wrap around to zero, causing that function to
return a small value.  That value would likely not exceed
MAX_ALLOC_CHUNK, so the subsequent size checks in alloc_small() and
alloc_large() would not catch the error.

A similar problem could occur in 32-bit builds if alloc_sarray() were
called with
samplesperrow > SIZE_MAX - (2 * ALIGN_SIZE / sizeof(JSAMPLE)) - 1

This patch simply ensures that the size argument to the alloc_*()
functions will never exceed MAX_ALLOC_CHUNK (1 billion).  If it did,
then subsequent size checks would eventually catch that error, so we
are instead catching the error before round_up_pow2() is called.

This addresses a minor concern (LJT-01-001) expressed in a security
audit by Cure53.

Fix Visual C++ compiler warnings

rdppm.c: formatting tweaks

jmemmgr.c: formatting tweaks

TurboJPEG: Avoid dangling pointers

This addresses a minor concern (LJT-01-002) expressed in a security
audit by Cure53.  _tjInitCompress() and _tjInitDecompress() call
(respectively) jpeg_mem_dest_tj() and jpeg_mem_src_tj() with a pointer
to a dummy buffer, in order to set up the destination/source manager.
The dummy buffer should never be used, but it's still better to make it
static so that the pointer in the destination/source manager always
points to a valid region of memory.

Adjust performance claims

Document the latest benchmarks on the Nexus 5X and change the "2-4x"
overall claim to "2-6x".  The peak performance on x86 platforms was
already closer to 5x, and the addition of SIMD-accelerated Huffman
encoding gave it that extra push over the cliff.

Use consistent formatting in ARM NEON SIMD code

There aren't really any best practices to follow here.  I tried as best
as I could to adopt a standard that would ease any future maintenance
burdens.  The basic tenets of that standard are:

* Assembly instructions always start on Column 5, and operands always
  start on Column 21, except:
  - The instruction and operand can be indented (usually by 2 spaces)
    to indicate a separate instruction stream.
  - If the instruction is within an enclosing .if block in a macro,
    it should always be indented relative to the .if block.
* Comments are placed with an eye toward readability.  There are always
  at least 2 spaces between the end of a line of code and the associated
  in-line comment.  Where it made sense, I tried to line up the comments
  in blocks, and some were shifted right to avoid overlap with
  neighboring instruction lines.  Not an exact science.
* Assembler directives and macros use 2-space indenting rules.  .if
  blocks are indented relative to the macro, and code within the .if
  blocks is indented relative to the .if directive.
* No extraneous spaces between operands.  Lining up the operands
  vertically did not really improve readability-- personally, I think it
  made it worse, since my eye would tend to lose its place in the
  uniform columns of characters.  Also, code with a lot of vertical
  alignment is really hard to maintain, since changing one line could
  necessitate changing a bunch of other lines to avoid spoiling the
  alignment.
* No extraneous spaces in #defines or other directives.  In general, the
  only extraneous spaces (other than indenting spaces) are between:
  - Instructions and operands
  - Operands and in-line comments
This standard should be more or less in keeping with other formatting
standards used within the project.

Opt. ARM64 SIMD decompr. for in-order pipelines

Decompression speedup relative to libjpeg-turbo 1.4.2 (ISLOW IDCT):
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 60-113% (avg. 86%)
Cortex-A53 (Nexus 5X), Android, 64-bit: 6.8-27% (avg. 14%)
Cortex-A57 (Nexus 5X), Android, 64-bit: 2.0-14% (avg. 6.8%)

Decompression speedup relative to libjpeg-turbo 1.4.2 (IFAST IDCT):
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 51-98% (avg. 75%)

Minimal speedup (1-5%) observed on iPhone 5S (Cortex-A7)

NOTE: This commit avoids the st3 instruction for non-Android and
non-Apple builds, which may cause a performance regression against
libjpeg-turbo 1.4.x on ARM64 systems that are running plain Linux.
Since ThunderX is the only platform known to suffer from slow ld3 and
st3 instructions, it is probably better to check for the CPU type
at run time and disable ld3/st3 only if ThunderX is detected.

This commit also enables the use of ld3 on Android platforms, which
should be a safe bet, at least for now.  This speeds up compression on
the afore-mentioned Nexus Cortex-A53 by 5.5-19% (avg. 12%) and on the
Nexus Cortex-A57 by 1.2-14% (avg. 6.3%), relative to the previous
commits.

This commit also removes unnecessary macros.

Refer to #52 for discussion.

Closes #52.

Based on:
https://github.com/mayeut/libjpeg-turbo/commit/6bad905034e6e73b33ebf07a74a6b72f58319f62
https://github.com/mayeut/libjpeg-turbo/commit/488dd7bf1726e2f6af6e9294ccf77b729fec1f20
https://github.com/mayeut/libjpeg-turbo/commit/4f4d057c1fb31d643536e6effb46a5946e15c465
https://github.com/mayeut/libjpeg-turbo/commit/d3198afc43450989a4fc63d2dcbe3272c8a0a3c1

Update Android build instr. for ARMv8, PIE, etc.

* Include information on how to do a 64-bit ARMv8 build with the latest
NDK
* Suggest -fPIE and -pie as default CFLAGS (required for android-16 and
later.
* Remove -fstrict-aliasing flag (-Wall already includes it)

Merge branch '1.4.x'

Makefile.am: formatting tweak

Update Android build instr. for ARMv8, PIE, etc.

* Include information on how to do a 64-bit ARMv8 build with the latest
NDK
* Suggest -fPIE and -pie as default CFLAGS (required for android-16 and
later.
* Remove -fstrict-aliasing flag (-Wall already includes it)

TJBench: Fix segfault on Android

For whatever reason, the "write" global variable in tjbench.c was
overriding the linkage with the write() system function.  This may have
affected other platforms as well but was not known to.

Provide pkg-config (.pc) scripts

This allows a project to use PKG_CHECK_MODULES() in its configure.ac
file to easily check for the presence of libjpeg-turbo and modify the
compiler/linker flags accordingly.  Note that if a project relies solely
on pkg-config to check for libjpeg-turbo, then it will not be possible
to build that project using libjpeg or an earlier version of
libjpeg-turbo.

Closes #53

Based on:
https://github.com/cberner/libjpeg-turbo/commit/496713871939b550d00005b4042420da41641a0a

Optimize ARM64 SIMD code for Cavium ThunderX

Per @ssvb:
ThunderX is an ARM64 chip that dedicates most of its transistor real
estate to providing 48 cores, so each core is not as fast as a result.
Each core is dual-issue & in-order for scalar instructions and has only
a single-issue half-width NEON unit, so the peak throughput is one
128-bit instruction per 2 cycles.  So careful instruction scheduling is
important.  Furthermore, ThunderX has an extremely slow implementation
of ld2 and ld3, so this commit implements the equivalent of those
instructions using ld1.

Compression speedup relative to libjpeg-turbo 1.4.2:
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 58-85% (avg. 74%)
relative to jpeg-6b: 1.75-2.14x (avg. 1.95x)

Refer to #49 and #51 for discussion.

Closes #51.

This commit also wordsmiths the ChangeLog entry (the ARMv8 SIMD
implementation is "complete" only for compression-- it still lacks some
decompression algorithms, as does the ARMv7 implementation.)

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

which is based on:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/f561944ff70adef65bb36212913bd28e6a2926d6
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/962c8ab21feb3d7fc2a7a1ec8d26f6b985bbb86f

Add JSIMD_NOHUFFENC environment variable for ARM

Useful in regression/performance testing

Complete the ARM64 NEON SIMD implementation

This adds 64-bit NEON coverage for all of the algorithms that are
covered by the 32-bit NEON implementation, except for h2v1 (4:2:2) fancy
upsampling (used when decompressing 4:2:2 JPEG images.)  It also adds
64-bit NEON SIMD coverage for:

* slow integer forward DCT (compressor)
* h2v2 (4:2:0) downsampling (compressor)
* h2v1 (4:2:2) downsampling (compressor)

which are not covered in the 32-bit implementation.

Compression speedups relative to libjpeg-turbo 1.4.2:
Apple A7 (iPhone 5S), iOS, 64-bit: 113-150% (reported)
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 2.1-33% (avg. 15%)

Refer to #44 and #49 for discussion

This commit also removes the unnecessary

    if (simd_support & JSIMD_ARM_NEON)

statements from the jsimd* algorithm functions.  Since the jsimd_can*()
functions check for the existence of NEON, the corresponding algorithm
functions will never be called if NEON isn't available.

Based on:
https://github.com/mayeut/libjpeg-turbo/commit/dcd9d84f10fae192c0e3935818dc289bca9c3e29
https://github.com/mayeut/libjpeg-turbo/commit/b0d87b811f37bd560083deea8c6e7d704e5cd944
https://github.com/mayeut/libjpeg-turbo/commit/70cd5c8a493a67f4d54dd2067ae6dedb65d95389
https://github.com/mayeut/libjpeg-turbo/commit/3e58d9a064648503c57ec2650ee79880f749a52b
https://github.com/mayeut/libjpeg-turbo/commit/837b19542f53fa81af83e6ba002d559877aaf597
https://github.com/mayeut/libjpeg-turbo/commit/73dc43ccc870c2e10ba893e9764b8e48d6836585
https://github.com/mayeut/libjpeg-turbo/commit/a82b71a261b4c0213f558baf4bc745f1c27356d8
https://github.com/mayeut/libjpeg-turbo/commit/c1b1188c2106d6ea7b76644b6023b57edeb602e1
https://github.com/mayeut/libjpeg-turbo/commit/305c89284e1bb222b34fbc7261f697a0cc452a41
https://github.com/mayeut/libjpeg-turbo/commit/7f443f99950b4d7d442b9b879648eca5273209bd
https://github.com/mayeut/libjpeg-turbo/commit/4c2b53b77da5a20e30e2aadaeddb0efbfe24e06d

Unified version with fixes:
https://github.com/mayeut/libjpeg-turbo/commit/1004a3cd05870612a194b410efeaa1b4da76d246

ARM32 NEON SIMD implementation of Huffman encoding

Full-color compression speedups relative to libjpeg-turbo 1.4.2:

800 MHz ARM Cortex-A9, iOS, 32-bit:  26-44% (avg. 32%)

Refer to #42 and #47 for discussion.

This commit also removes the unnecessary

    if (simd_support & JSIMD_ARM_NEON)

statements from the jsimd* algorithm functions.  Since the jsimd_can*()
functions check for the existence of NEON, the corresponding algorithm
functions will never be called if NEON isn't available.  Removing those
if statements improved performance across the board by a couple of
percent.

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

tjbench: Further tweaks to -nowrite feature

* Do not compute compression error if -nowrite is specified
* Adjust formatting of -nowrite usage description

BUILDING.md: Restore autotools processing instr.

Partially reverts 54014d9c2a41905b7b766057af6728834da64b59.  When
building from a git sandbox, as opposed to from an official source
tarball, it is still necessary to run autoreconf.

Closes #48

Update build instructions for new autoconf, GitHub

The Linux build machine has been upgraded to autoconf 2.69, automake
1.15, m4 1.4.17, and libtool 2.4.6, so it is no longer necessary to
recommend running autoreconf prior to building the source, if one is
building from an official source tarball (as opposed to from a git
sandbox.)  Also, there is no SVN repository anymore (oops.)

SSE2 SIMD implementation of Huffman encoding

Full-color compression speedups relative to libjpeg-turbo 1.4.2:

2.8 GHz Intel Xeon W3530, Linux, 64-bit:  2.2-18% (avg. 9.5%)
2.8 GHz Intel Xeon W3530, Linux, 32-bit:  10-25% (avg. 17%)

2.3 GHz AMD A10-4600M APU, Linux, 64-bit:  4.9-17% (avg. 11%)
2.3 GHz AMD A10-4600M APU, Linux, 32-bit:  8.8-19% (avg. 15%)

3.0 GHz Intel Core i7, OS X, 64-bit:  3.5-16% (avg. 10%)
3.0 GHz Intel Core i7, OS X, 32-bit:  4.8-14% (avg. 11%)

2.6 GHz AMD Athlon 64 X2 5050e:
Performance-neutral (give or take a few percent)

Full-color compression speedups relative to IPP:

2.8 GHz Intel Xeon W3530, Linux, 64-bit:  4.8-34% (avg. 19%)
2.8 GHz Intel Xeon W3530, Linux, 32-bit:  -19%-7.0% (avg. -7.0%)

Refer to #42 for discussion.  Numerous other approaches were attempted,
but this one proved to be the most performant across all platforms.

This commit also fixes #3 (works around, really-- the clang-compiled version
of jchuff.c still performs 20% worse than its GCC-compiled counterpart, but
that code is now bypassed by the new SSE2 Huffman algorithm.)

Based on:
https://github.com/mayeut/libjpeg-turbo/commit/2cb4d41330e1edc4469f6b97ba73b73abfbeb02f
https://github.com/mayeut/libjpeg-turbo/commit/36c94e050d117912adbff9fbcc6fe307df240168

Add -nowrite arg to TJBench to improve consistency

Prevents any images from being written to disk, thus making the
performance of the benchmark as CPU-bound as possible.

Allow JSIMD_FORCENONE=1 env to disable x86-64 SIMD

Traditionally, the x86-64 code did not call init_simd() because it had
no need to (only SSE2 was supported.)  However, having the ability to
disable SIMD at run time is a useful testing tool, and all of the other
SIMD implementations have this ability.

1.4.3

Merge branch '1.4.x'

Regression: Allow co-install of 32-bit/64-bit RPMs

Fix a regression introduced in 1.4.1 that prevented 32-bit and 64-bit
libjpeg-turbo RPMs from being installed simultaneously on recent Red
Hat/Fedora distributions.  This was due to the addition of the
SIZEOF_SIZE_T macro in jconfig.h, which allows the Huffman codec to
determine the word size at compile time.  Since that macro differs
between 32-bit and 64-bit builds, this caused a conflict between the
i386 and x86_64 RPMs (any differing files, other than executables, are
not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
Since the macro is used only internally, it has been moved into
jconfigint.h.

Fix iOS ARM64 build broken by removal of .arch

The unnecessary .arch directive was removed from the ARM64 SIMD code
in d70a5c12fcb72443483456a2cc8dd18a4c238618, thus allowing clang's
integrated assembler to assemble the code on Linux systems.  However,
this broke the detection mechanism in acinclude.m4 that tells the build
system whether it needs to use gas-preprocessor.pl.  Since one of the
primary motivators for using gas-preprocessor.pl with ARM64 builds is
the lack of .req/.unreq directives in Apple's implementation of clang,
acinclude.m4 now checks whether .req/.unreq can be properly assembled
and uses gas-preprocessor.pl if not.

Closes #33.

Merge branch '1.4.x'

Build: Use FILEPATH type for NASM CMake variable

This causes cmake-gui to to display the proper file chooser dialog
(as opposed to the directory chooser.)

Fixes #40

cjpeg: Adjust claims RE: image quality settings

Quality values > 95 are not useless.  They just may not provide as good
of a size vs. perceptual quality tradeoff as lower quality values.  This
also displays the default quality value in the cjpeg usage.

Closes #39

Remove unnecessary .arch directive in ARM64 code

This directive was preventing the code from assembling using the
integrated assembler in clang.

Fixes #33

Fix compiler warnings under Visual C++

A few of these are long-standing, but most were exposed when switching
from INT32 to JLONG.

Fix additional issues reported by UB sanitizers

Most of these involved overrunning the signed 32-bit JLONG type whenever
building libjpeg-turbo with a 32-bit compiler.  These issues are not
believed to represent actual security threats, but eliminating them
makes it easier to detect such threats should they arise in the future.

Replace INT32 with a new internal datatype (JLONG)

These days, INT32 is a commonly-defined datatype in system headers.  We
cannot eliminate the definition of that datatype from jmorecfg.h, since
the INT32 typedef has technically been part of the libjpeg API since
version 5 (1994.)  However, using INT32 internally is risky, because the
inclusion of a particular header (Xmd.h, for instance) could change the
definition of INT32 from long to int on 64-bit platforms and thus change
the internal behavior of libjpeg-turbo in unexpected ways (for instance,
failing to correctly set __INT32_IS_ACTUALLY_LONG to match the INT32
typedef-- perhaps as a result of including the wrong version of
jpeglib.h-- could cause libjpeg-turbo to produce incorrect results.)

The library has always been built in environments in which INT32 is
effectively long (on Windows, long is always 32-bit, so effectively it's
the same as int), so it makes sense to turn INT32 into an explicitly
long datatype.  This ensures that libjpeg-turbo will always behave
consistently, regardless of the headers included at compile time.

Addresses a concern expressed in #26.

ChangeLog: acknowledge existence of 1.4.2

README.md: create link for jcstest.c

Markdown versions of README, LICENSE, BUILDING

Rename README, LICENSE, BUILDING text files

The IJG README file has been renamed to README.ijg, in order to avoid
confusion (many people were assuming that that was our project's README
file and weren't reading README-turbo.txt) and to lay the groundwork for
markdown versions of the libjpeg-turbo README and build instructions.

Merge branch '1.4.x'

Comment formatting tweaks

Fix 'make dist'

1.4.2