New fixes available

[Hauke Heibel]

Hi Adam,

Probably resulting from the merge with 'cairo', there were a few new
issues introduced regarding MSVC builds.

I update my repository with your master and integrated the required
fixes. The changes can be found here:

http://github.com/hauke76/OpenSlide/

Changelog (these changes are split up in different commits):
- CMake adpations that enable the usage of png, tiff, jpeg and
openjpeg builds from ITK (standard builds still work)
- Removed redundant includes from openslide-jdatasrc.c
- Fixed struct initialization in openslide-ops-ngr.c
- Guarded inttypes.h include (not required on MSVC)
- Fixed goto statements; renamed OUT to DONE. OUT is a predefined macro on MSVC.
- Introduced reinterpret casts between uint32_t* and uint32 (see previous mail).
- Included the jpeglib.h explicitly as C code when building OpenSlide
as C++ code.

The last issue is a bit ugly. It it required because of the different
calling conventions and currently it does not capture cases where a
Windows user were using a C++ build jpeglib (as I did when working the
last time with OpenSlide). The real fix would be to introduce a CMake
mechanism that determines whether the jpeglib requires this guard (I
know how to do it and will do it when I find the time).

The inttypes guard (would also be required for stdbool which I removed
from openslide-jdatasrc.c) implies that we might consider providing a
single header file with these includes. Maybe openslide-private is the
one I am thinking about. Then it would be great if it were sufficient
for new modules to include this header file which should take care of
bools and inttypes and maybe also the third party includes. Thus we
could prevent new errors on different systems. Maybe one could also
consider having something like openslide-types that only deals with
the standard includes, bools and inttypes and maybe some macros. Well,
I think you know what I mean.

Regards,
Hauke