[python] Restructure module metadata file logic and use to solve 'mpi4py' issue

Fixes #271 (closed) Alternative to !1044 (closed)

This patch changes the generation of the metadata files used to store cmake flags which are needed to generate a compatible dune-py. With this change it is fairly easy to test if HAVE_MPI is true if so to then abort if mpi4py could not be imported.

Changes

1. store the metadata in dune/data/modulename.cmake
2. setup the metadata structure in packagemetadata.py and also extract the cmake flags there.
3. add a test for HAVE_MPI in dune/common/__init__.py

Consequence:

• the CMAKE_METADATA_FILE parameter to dune_python_install_package is not used anymore.
• to obtain the metadata does not require to import all subpackages anymore. This avoids educes start up time and avoids issues with circular imports.

MPI4PY

I combined this approach now with the ideas from !1044 (closed). So

• source build: if MPI_FOUND is true mpi4py will be added to the requirements in the install python package function so that mpi4py will be added to the (internal) venv.
• package build: using the metadata file we can check if HAVE_MPI was set during the configuration of dune-common. In python/dune/common/__init__.py we check if HAVE_MPI was true and mpi4py cannot be found. In that case the script is terminated with a message informing the user to run pip install mpi4py.