- Fix python code that is injected into python interpreter
- Proper error handling => fatal_error to stop cmake run if numpy not found

This can happen if python has been compiled with a specialized
malloc.

This commit doesn't make OpenStructure work with Python 3. The goal of this
commit was to perform an automated port of the Python code and make it compile.
The performed steps:

- Edited CMakeLists.txt to search for Python with 3.6 as min version 3.6 is the
  Python version shipped by default with Ubuntu 18.04 LTS
- Add version 3.6 to cmake_support/FindPython.cmake
- Adapt setup_boost macro in cmake_support/OST.cmake to prefer versioned
  libraries and not first check for boost_python.so. In the example of
  Ubuntu 18.04, libboost_python.so is specific for Python 2 but
  libboost_python3.so is the one we want.
- apply the following command: 2to3-2.7 -n -w <OST_DIR>
- adapt base/pymod/wrap_base.cc, gui/pymod/wrap_gui.cc and
  gui/pymod/export_message_widget.cc as PyString functionalities do not exist
  anymore in the Python 3 interpreter (replaced by PyUnicode)
- adapt gui/src/python_shell/python_interpreter_worker.hh to resolve issue
  discussed in https://stackoverflow.com/questions/23068700/embedding-python3-in-qt-5
  Long story short: Qt does a typedef for "slots" which causes trouble with
  other headers that are pulled in from the Python interpreter

Tested with Ubuntu 18.04 (in a vagrant box) following instructions in doc and
adding cmake flags "-DENABLE_STATIC=ON -DENABLE_INFO=OFF". Tested resulting
binaries "chemdict_tool" and "lddt" in Ubuntu-box and host-system (CentOS 7).

The reason is that we want to profit from latest security updates and
therefore not use a copy of the SQLite3 source code that becomes outdated.

ToDo: test on different Linux distributions / bc2 and adapt compile
instructions accordingly, also container recipes must be adapted.

takes care of the case where the resolution of the path of a dependency already point to a library within the bundle

added libexec dir to OSX deployment cmake script
fixed path to python library for OSX packaging

OpenMM library

run cmake with -DENABLE_MM=1
if you can successfully compile, check out the examples in the
modules/mol/mm/examples directory

/System/Library/Frameworks in addition to /Library/Frameworks

Fixed issue in FindPython: requested Python version was only tested to be bigger than requirement, not equal to

Refactored FindEigen.cmake to adhere to cmake guidelines
Adapted master CMakeLists.txt to changes in find modules

A little less hackish solution. Thanks to Andi for the suggestion