using which only works, if `generate_operators` is in `PATH`, otherwise cmake fails. This is especially the case if dune-codegen is configured completely new.

Enable with the cmake variable DUNE_CODEGEN_PROFILING. For each generated header,
a profile is written out. These can be visualized with tools like snakeviz.

I have the use case of a boundary condition file, whose changes should retrigger
the code generation process.

CMakes add_custom_command occasionally (undeterministically)
trips over when multiple files are defined as output. The
result is unnecessary regeneration upon every change of the
accompanying C++ source...

The commit fixes the issue by defining one custom command per
operator. This has the additional pro of generating more verbose
messages during generation. Implementation wise, CMake needed
to extract more information from the ini file, so I switched
to using dune-testtools Python-CMake interface.

Also allow the usage of the __static section (as known from dune-testtools).
However, variation in the static section is not yet considered!

Instationary stuff not fixed so far.

So far, changes in the form compiler did not trigger code regeneration
if invoked from a downstream dune module. This is fixed now.

The previous test timeout of 20s seems to be insufficient sometimes.  Raise it
to 60s.

That allows us to load that file as a pandas frame.

Instead return a bool that influences the return code