Forcing Z_CONST resulted in an issue when compiling Firefox.  Now
if someone wants to compile zlib as C++ code (which it isn't), now
they will need to #define Z_CONST themselves.

If the compressed data was already at a block boundary, then
deflateParam() would report Z_BUF_ERROR, because there was nothing
to write.  With this patch, Z_OK is returned in that case.

You would still need to run zlib2ansi on all of the *.c files.

That didn't work when cross-compiling.  Simply rely on limits.h.
If a compiler does not have limits.h, then zconf.h.in should be
modified to define Z_U4 as an unsiged four-byte integer type in
order for crc32() to be fast.

This also simplifies and makes more portable to check for a four-
byte type using limits.h.

The function is only available if stdarg.h is available.

 * Use -DASM686=1 to build with i686 asm.
 * Use -DAMD64=1 to build with amd64 asm.

Facilitate multi-platform compilation, e.g.:
nmake -f pathto\zlib\win32\Makefile.msc TOP=pathto\zlib

Mac OS X's linker (derived from LLVM, not GNU binutils) does not support
--version-script. Don't specify it on this platform.

Previously, spaces in ${CMAKE_CURRENT_SOURCE_PATH} would expand into
multiple linker arguments.

Also correct typo for 64-bit debug build.

Suggested by E. Timothy Uy.

inftrees.c compared the number of used table entries to the maximum
allowed value using >= instead of >.  This patch fixes those to use
>.  The bug was discovered by Ignat Kolesnichenko of Yandex LC
where they have run petabytes of data through zlib.  Triggering the
bug is apparently very rare, seeing as how it has been out there in
the wild for almost three years before being discovered.  The bug
is instantiated only if the exact maximum number of decoding table
entries, ENOUGH_DISTS or ENOUGH_LENS is used by the block being
decoded, resulting in the false positive of overflowing the table.

Without this fix, it would be possible to construct inputs to puff
that would cause it to segfault.