Using LocalIndexSet objects was mandatory with dune-functions-2.5
and earlier.  However, we only support 2.6 and later anyway,
so let's get rid of the backward-compatibility code.

In the test, the grid dimension was defined twice:  Once globally
at the top of the file, and once through a chain of template parameters.
This patch removes the global variable.

Because it really is a functionality of rotation matrices in quaternion
representation.  Only the Cosserat energies use it at the moment, but
this is coincidental.

In the same process, the method is renamed to quaternionTangentToMatrixTangent.
That seems to be a more telling name.

In particular, we move the test for the computeDR method from
cosseratenergytest.cc to here.  It is a method that does not
have anything to do with Cosserat mechanics directly.

The test still seems overly complicated.  Do I really need
a LocalGeodesicFEFunction?  Maybe I can simplify it later.

* Do not test with configurations that result in zero-area elements
  (because the energy is inf in these cases).
* Test for the relative energy difference, rather than the absolute one,
  because the energy values can get very large.

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.