Previously, this test used a situation with geodesic interpolation
between two points on the sphere that are almost antipodal.
This made the TargetSpaceRiemannianTRSolver crash, because the
weighted sum of squared distances can have indefinite second
derivatives in such a situation.  In principle, the
TargetSpaceRiemannianTRSolver should handle this, but nowadays
it is not actually a TR solver anymore, but a plain local
Newton method.  Maybe I should revert back to trust-region.

I added a comment to targetspacetrsolver.cc that explains the
situation a little.

There is really no point in having this method.  Before it is called,
localgeodesicfefunctiontest already checks whether the derivative
is correct (by comparing with an FD approximation).  If a derivative
passes this test it MUST be tangential.  No need to check that
explicitly.

It is not clear what this method was supposed to test,
because the CosseratEnergyStiffness class does not
actually implement a the gradient.

To prevent confusion with a class of the same name in
dune-localfunctions.

All of a sudden it gets confused with a class of the same name
in dune-localfunctions.

It's not clear what it is supposed to be testing at all.

And make it actually test something.

Previously the code only tested whether the AverageDistanceAssembler
computed gradient vector and Hesse matrix.  Now the test actually
tests whether these are correct.

To make it clear that that test does not currently test anything.

I forgot the GridFactory::createGrid did return a plain pointer
as recently as dune-grid 2.6.

This is what GridFactory::createGrid returns anyway.

It is no test.  Rather, it is a program I used to create illustrations
for the paper on GFE test functions (arXiv:1607.07479).  I moved the
program into the git repository of that paper.

This was never a real test.  Rather, it was I toy for me to test
a mathematical property of GFE functions which is known to be
false anyway.

That's already done in adolcnamespaceinjections.hh, in dune-fufem.

This resolves a name ambiguity.

Capturing any polymorphic object by value is wrong,
and gcc 8 started to warn about this in the case
of exceptions.

The latter is deprecated as of dune-functions 2.6.

This makes the test build again.

It also removes the FD test for the gradient of the harmonic energy.
Since the HarmonicEnergyStiffness class does not implement the
gradient anymore, there is nothing to test here.

Otherwise some dune-common stuff will not work properly,
for example copying of FieldMatrices that use adouble
as their number type.