Allow setting up wheels for OSX by not linking python

[y0ast]

This is the CMAKE fix for OSX, similar to discussed in #138

It will remove python/Frameworks/Python.framework/Versions/2.7/Python link in dlib.so and therefore allow building a wheel.

before:

$ otool -L python_examples/dlib.so
python_examples/dlib.so:
	@rpath/dlib.so (compatibility version 0.0.0, current version 0.0.0)
	/<path-to-package>/boost-python/lib/libboost_python-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/<path-to-package>/python/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
	/opt/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0)
	/opt/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/X11/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/<path-to-package>/libpng/lib/libpng16.16.dylib (compatibility version 46.0.0, current version 46.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 254.5.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)

after:

$ otool -L python_examples/dlib.so
python_examples/dlib.so:
	@rpath/dlib.so (compatibility version 0.0.0, current version 0.0.0)
	/<path-to-package>/boost-python/lib/libboost_python-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0)
	/opt/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/X11/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/<path-to-package>/libpng/lib/libpng16.16.dylib (compatibility version 46.0.0, current version 46.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 254.5.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)

Also relevant for @matthew-brett

[y0ast]

Also here is a relevant blogpost explaining the situation: http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/

[davisking]

If you take a copy of dlib with this change and run these commands:

cd tools/pyhton
mkdir build
cd build
cmake ..
make install
cd ../../../python_examples
./svm_rank.py

What happens? Does it work? As I mentioned in the other PR, existing usage of dlib should still work with these PRs.

[y0ast]

closing in favor of #703