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.