This is needed to test against the 2.6 core modules.

This new test computes a harmonic map from a square to a sphere.
In other words, rather than testing some specific aspect of some
class, it does a whole simulation.  It should therefore cover
much more of the dune-gfe code.

Automatic testing of the RiemannianTrustRegionSolver class requires
to know what it did on the previous run.  This patch adds
some infrastructure to collect this information.

I wrote it without a clear idea of what is needed of such a
test function, and I never finished it.  Now it is unclear
what the code does or is supposed to do, so let's just
remove it.

.gitlab-ci.yml: test with dune-parmg installed and other configurations

See merge request !24

Use only LocalView objects, no LocalIndexSet ones

See merge request !23

This avoids 'implicit narrowing' errors/warnings.

For some reason only clang complains about this.

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.

In principle, a serious bug: but for dimworld=3d (i.e., the standard)
this loop was never executed anyway.  Hence there were no serious
consequences.

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.

Assignment from initializer lists makes this much shorter.

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.

The computation of the A-orthogonal matrices was wrong,
and for some reason nobody ever really noticed this.
One reason could be that in GFE applications A is frequently
very close to the identity, and then you wouldn't notice
the bug that much.

Anyway, localgeodesicfefunctiontest.cc passes now.

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.

In favor of the new ones in dune-common.

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

For some reason I must have forgotten to check in this file when
first converting to the cmake build system.