Numpy support in C++ enabled features at two points:
Efficient way of setting positions in entity handles or setting meshes
in gfx.PrimList.

Support for newer numpy versions would've required an effort to implement.
As far as I know, no one uses these features (fingers crossed) so let's just
dump numpy alltogether to simplify the build system.

This sets up the compound lib upon calling import ost.
It simplifies the ost_startup.py script accordingly.
It is now possible to override the compound lib with
an environment variable: OST_COMPOUNDS_CHEMLIB

You might have to adapt CMake flags when building OpenStructure to variables specified here:
https://cmake.org/cmake/help/latest/module/FindPython.html

execfile has been replaced by exec in Python 3

Executed command: 2to3-2.7 -n -w scripts/ost_startup.py.in

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

fixes problems for users with read-only home directories. Plus,
it's easy enough for the user to create the file when it's
needed

Substitutes DEBIAN_STYLE_LIBEXEC flag and manages location and name of lib and libexec folders on Debian/Ubuntu-based systems

since the ost startup script lives in the same directory as the
top-level ost modules (python{version}/site-packages/ost), the
directory got automatically added to sys.path. That's bad for
several reasons I don't want to go in right now (see discussion
on the mailing list). Instead of passing the script as a script
name to execute, we now use execfile with the startup script.
This circumvents addition of the directory to the path and
makes Gabriel smile again.