Up until dune-common 2.7, the Dune namespace contained shared_ptr:
First as an actual implementation, later simply as a namespace
import.  Dune-common post-2.7 has removed that import,
and users of shared_ptr really have to explicitly specify
the std:: namespace prefix.

The svd code contains some index trickery, because the original code
was written in fortran, which numbers arrays starting from '1'
rather than from '0'.  This trickery included having a pointer point
1 int in front of an allocated array, implicitly relying on the
fact that pointer[0] would never be called.  The llvm sanitizer
complains nevertheless, so this patch improves the trickery a little
to avoid the objected pointer.

Do this by making RodAssembler more similar to the generic
GeodesicFEAssembler: the constructor argument is now a
general LocalGeodesicFEStiffness, and not something particular
to rod problems.

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.

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 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.

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.

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.

In favor of the new ones in dune-common.

Because it really is only an energy.

Because it is not a stiffness, it is really just an energy.

It is still part of the official matrix interface, but I doubt
that anybody actually uses it.  I'd rather see blocklevel gone
and replaced by modern C++ introspection.  Let's remove it here
and see who complains.

The dune-common 2.7 release finally adds all those standard
binary addition, multiplication, etc operators for FieldVector
and FieldMatrix.  Hence we do not have to have our own
implementation anymore.  We still keep it for backward-
compatibility with dune-common 2.6, but guard it behind
cpp conditionals.

Previously, they all inherited from LocalGeodesicFEStiffness,
which was weird, because none of them implemented first or
second derivatives as you would expect from something called
'stiffness'.

This makes the methods AverageDistanceAssembler::assembleHessian
compile again.  And it should be a wee bit faster two, because
matrix symmetry is now exploited better.

Because a Stiffness does provide a first derivative.

LocalFirstOrderModel will be an abstract base class for models that
implement an energy and a first (not no second) derivative.

A LocalGeodesicFEStiffness 'is a' LocalFirstOrderModel, which 'is a'
LocalEnergy.

... rather than a LocalGeodesicFEStiffness.  That is a much
cleaner design -- A 'stiffness' produces first and second
derivatives for an 'energy'.

Currently, all implementations of variational problems inherit
from LocalGeodesicFEStiffness, which requires gradient and Hessian
implementations.  However, most of these implementations really
only implement the energy, and leave computations of first and
second derivatives to algorithmic differentiation.  To make
this clearer, this patch introduces an abstract base class
LocalEnergy for all implementations that really only have
an energy.

Throw out the AmiraMesh support instead.  I have not seen
anybody using Amira for years.