It still tested for the dune-fufem wrapper of a first-order basis, while nowadays
the RiemannianTRSolver class is instantiated with dune-functions bases.

It is still no function in the dune-functions sense, but at least the
basis parameter needs to be a dune-functions basis now, rather than
a deprecated dune-fufem basis.

This is needed to be able to multiply FieldMatrices with Quaternions.

Needed for gradient-flow applications.

According to Hanne, this is needed to turn 1d harmonic map heat flow into true
curve-shortening flow.

Hardwiring the weighting here is very hacky.  Something more flexible and
general will need to be implemented eventually.

Apparently, nobody had used the evaluateDerivativeLocal method before.

This are needed by the gradientflow code to implement the implicit Euler method
for an L2 gradient flow.

This is an initial version; it currently only works for a very limited set of
cases.  I tested it for triangle grids, and that works.

This is needed for the new gradientflow application.  The standard 'distance' method
doesn't cut it, because it is not differentiable near zero.  Therefore, even the
differentiable expression 'distance*distance' will fail to be differentiable for
an automatic-differentiation system.  I think in the long run we should replace
'distance' by 'distanceSquared' everywhere it is used.

Unfortunately, this patch is hacky: it only adds the method for the double/adouble
combination.

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.

For some reason clang doesn't like it, and we are not using OpenMP anyway.

I want this file with dimworld!=3 grids, even though it only makes sense
to use it if dimworld==3.

With this patch the file still does not compile.  However, the only remaining
problem is the hacky computation of the surface normals, which needs to be
rewritten in full generality soon anyway.

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

The method using the SVD works in principle.  However, it does not play nicely
with automatic differentiation, because singular values are not always differentiable.

The method proposed by Higham to compute the polar factor, on the other hand,
is a Newton method at heart.  Therefore, it can be used together with AD without
problems.

They only make sense if the 'adouble' type is known.

I intend to move as much towards the dune-functions interface for functions,
and this is a first step.

Introduce preprocessor variable PROJECTED_INTERPOLATION to switch between geodesic FE and projection-based FE

This is a temporary solution; we need something smarter eventually.

Rationale
a) Code is much simpler without it
b) Code compiles faster without it
c) P3 functions are now downsampled to P2 functions, rather than to P1 functions.
   Hence there is less loss of information now.

Simply ask the first local finite element of the dune-functions basis for the order.

Introduce a dedicated class LocalQuickAndDirtyFEFunction to produce initial iterates for the GFE minimization problems

Previously, a LocalProjectedFEFunction was used for this.  This turned out to be a bad idea for two reasons:
- Evaluating such a function can actually pretty expensive.  For example,
  to project onto SO(3), the polar decomposition needs to be evaluated by
  an iterative method.
- Screwing up the LocalProjectedFEFunction implementation can actually screw up
  the GFE implementation as well in very subtle ways.  Specifically, if the
  LocalProjectedFEFunction is not ADOL-C-differentiable, then the GFE function
  will not be differentiable, either.  This fact cost me a few hours searching...

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 how the new dune-functions bases should be used.  Also, it is yet
another step towards merging CosseratEnergyLocalStiffness and MixedCosseratEnergy.

This model was given to me by Patrizio Neff in private communication.

The code is a prototype.  It appears to work, but it has not been tested very
thoroughly, and quite likely there are some bugs left.  Also, the code contains
the shape of the reference configuration hard-wired (a sphere).

This patch adds several more implementations of operator+ etc for FieldMatrices.
In particular, you can now combine matrices of adoubles (the 'active' type from
the ADOL-C automatic differentiation library) with regular double types.

These new operators are needed for the NonplanarCosseratShellEnergy class,
which is coming in the next patch.