This will leave the coverage of the testing suite untouched!

They are only to a lesser extent important for our HPC applications
and the vectorization algorithm struggles with the complexity of the
search space.

It is not necessary anymore

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.

It would be hard to implement on top of the latest feature and contradict
features projected for the near future.

Instationary stuff not fixed so far.

The previous name was *really* confusing.

Much more telling name...

Useful, if you are only interested in the jacobian_apply versions
anyway.

It's completely unmaintained andI doubt that it will
at some point what it was intended for...

These might sound completely silly, but they are useful when writing
code generic w.r.t. the number of components

will be superseded by our actual model anyway.

It always aims for maximally horizontal vectorization
where possible.