[bin][pub] Rethink structure of extractmodulepart and createdockerimage

When using extractmodulepart.sh an install script is generated that pulls the dependencies. These are pulled within the directory of execution -> thus, the workflow at the end is that you pull the pub-module and then execute the install script from one level above it. Afterwards, you would run dunecontrol manually.

I think many people create their own (pub-)module directly when they start working on code that could lead to a publication and develop the code therein. In that case the extractmodulepart.sh step could be obsolete, and we could think about separating the install script generation from module extraction.

Also, it might be more convenient to write the install script such that one calls it directly from the folder of the pulled pub-module. Or alternatively, the install script could be such that it clones all repositories and also runs dunecontrol. Then one could do:

wget MY_PUB_MODULE_INSTALL_SCRIPT
chmod +x install.sh
./install.sh

The createdockerimage script assumes the type of install script that comes from extractmodulepart.sh, as it puts the following logic in the DockerFile:

• Copy module in image
• Copy install script in image top dumux folder
• Run install script
• Run dunecontrol

So, this would (probably) be incompatible with types of install scripts other than the ones resulting from extractmodulepart.sh.

Maybe we could think about factorizing/restructuring things. It would be good if createdockerimage had less requirements on the structure of the module, its install script and the place from where it must be executed.