You never know, we may be doing dim!=dimworld grids eventually.

Of course we always need unitvector.hh.  vtkadapter.hh, on the other hand, only
exists in dune-functions 2.4.

This is needed even though we don't actually use MPI here.  Dune aborts with a
run-time error otherwise.

It is so uncompileable that I am not able to fix it quickly.  Since I don't
actually need it right now I let it wait for another day.

And make that code path work again!

That should work when calling the executable from 'build-cmake/src'.

This initial commit simply brings a cleaned-up version of the harmonicmaps program.
The first step will be to make it compute curve-shortening flow on the sphere.

Previously, the NonplanarCosseratShellEnergy had the normal field of the unit sphere
hard-wired in the code.  With this patch, using general triangulated surface as
reference geometries is possible.

This allows to select the energy at run-time, but this is not what we do.
It also allows to give extra parameters to the nonplanar Cosserat energy,
and that is what we need: in a subsequent patch the main program will compute
a surface normal field and pass it to the Nonplanar Cosserat energy.

Here is a new program that does nothing but compute discretization errors:
that is L2 and H1 norms of differences between two functions.  The reference
function can be either discrete or given in closed form (the latter is not
enabled yet).

So far I have only used this program to measure discretization errors of
Cosserat shell models, and I did *not* get the error behavior I expected.
So either the error behavior of such shells is weird, or this new measurement
program is still buggy.

We can now completely control the approximation order by a const int,
which is much nicer.

This data is used by the compute-disc-error program to measure discretization errors.

Because these two classes are for the most part identical.

Currently, this merged version involves some trickery, including some template
specializations and multiple inheritances.  I hope to get rid of that, eventually.

This is an important step towards making the 'mixed' Cosserat code more like
the regular one.  The mid-term goal is to merge the two implementations, because
there is way too much code duplication here.

... with values expected to be given in the parameter file.

Scaling the trust region is the key to success, because in general the midsurface
deformation and the rotations will have values in different ranges.