Force-pushed to correct a couple of formatting issues and fix the Windows build.

In the next release writing high depth jpeg files will require setting the jpeg:high-bit-depth define. This will not be enabled by default anymore because a lot of decoders will not support reading these kind of files.

Playing Devil's advocate, can't users simply force the output bit depth to 8 if they want compatibility with more limited decoders? If you convert, say, a 16-bit PPM image into a 16-bit TIFF or PNG image, ImageMagick doesn't silently drop the bit depth in order to preserve backward compatibility with more limited decoders. It fully uses the capabilities of the most popular TIFF and PNG decoders. libjpeg-turbo is the most popular JPEG decoder, as well as the official ISO/ITU-T reference implementation.

My main concern is that there may be a chicken-and-egg issue. If ImageMagick supports all JPEG-1 variants by default, then it will encourage other applications to do likewise, and those other applications can now easily do so by using libjpeg-turbo. However, if ImageMagick doesn't support all JPEG-1 variants by default, then other applications will have little impetus to do so, and higher-bit-depth and lossless images will remain orphaned even though they are conformant JPEG-1 images.

Perhaps disabling jpeg:high-bit-depth by default could be temporary, until libjpeg-turbo 3.0.x and later become more widely available in operating systems? Or perhaps it could be enabled by default only if ImageMagick is built with libjpeg-turbo 3.1.x and later?

A bit of historical context:
libjpeg originated in an era before shared libraries were common, so it was designed to be compiled and linked statically with individual applications. Thus, it supports 12-bit lossy JPEG images, but only if you recompile it in a way that collides with the namespace of, and breaks API/ABI compatibility with, the 8-bit version of the library. Thus, the default feature set of libjpeg became canonical once the library was integrated into Linux and other operating systems. That limited the adoption of 12-bit lossy JPEG images, even though technically they have been supported all along. Similarly, Tom Lane stepped away from the IJG before he could integrate lossless support, so people who wanted to encode/decode lossless JPEG images had to compile libjpeg with Ken Murchison's patch that also collides and breaks compatibility with the 8-bit lossy version of the library. That limited the adoption of lossless JPEG images. libjpeg-turbo attempts to address those historical limitations by providing support for all JPEG-1 variants using the same API/ABI.

Even common browsers (firefox, google chrome) don't support 12-bit jpeg and I just found out about that (after Image Magick upgrade (to 7.1.2-9) which "broke" thumbnail generation on some web pages. Now on 7.1.2-13, so problem solved here).