use libjpeg-turbo, use common libs with crengine

Switch libjpeg to libjpeg-turbo: This will give a slight performance
advantage. Also, it will offer us the Turbo-JPEG API, which is a much
simpler approach to render JPEG/JFIF data. This is without
setjmp/longjmp exceptions and will allow for an easy FFI-based pic_jpeg
interface.

Also fix dependencies of our CREngine integration to use the common
build of Freetype, libpng and jpeg (using libjpeg-turbo). This will
mainly make the resulting library smaller, and remove redundant code.
fix libjpeg include path specification for MuPDF

I'm actually not sure why this has worked before. The error crept up
the first time for me here.
use common zlib with CREngine

use our own zlib build with CREngine (needed when the sysroot/system
does not provide a zlib - also this will use a known version)
fix win32 port
And also revert the lazily load pthread.
It seems that luajit cannot resolve symbols recursively from dynamically linked
libraries like in the linux. So that we do need to get platform specific pthread
libraries in different platforms. So does the mupdf library.
make test only if compilation succeeded
fix Travis building error of 'no nasm (Netwide Assembler) found'
fix android build
Merge pull request #4 from chrox/master

fix win32 port
Merge pull request #243 from hwhw/master

use libjpeg-turbo, use common libs with crengine