Fix dune-python raise condition

fixes #295 (closed) fixes ci-config#3 (closed)

In order to fix raise conditions in the internal dune-python builds, we have to fix parts of the locking and compilation process.

1. If two python scripts try to use the same module and the module is not yet present, they both detect that they have to build the module. The cmake setup is protected by an exclusive lock, but when the second process finally acquires the lock, the module is already present and the build finishes immediately, leading to _io.BufferedReader error.
2. For the actual compilation the module is protected by a shared lock. This ensures that there are no parallel explicit cmake calls (via 1.) while make is running. In the case of parallel builds, we can now have the situation, that two processes try to build something and for what ever reason, cmake implicitly triggers an implicit reconfiguration. This fails with these strange FindMPI error.

This MR implements the following fixes:

• after acquiring the the exclusive lock, we recheck presence of the module and potentially skip the setup phase.
• also the implicit cmake runs must be protected by a lock. I propose to do the locking internally in the dune-python module, instead of externally in cmakebuilde.py.