Otherwise the Cosserat rod code will not compile without dune-parmg.

So far, the Cosserat rod energy implementation hat a first-order
finite element space hardcoded.  This patch removes that restriction.
As for the other models in this Dune module, the finite element basis
is now a template parameter of the model energy, and can be set to
any reasonable basis.

It is not a 'stiffness' anymore, but really only implements the
energy.

Previously, the rod3d code used a hand-implemented first derivative
of the rod energy, and FD for the second derivatives.  This patch
replaces this by ADOL-C for both first and second derivatives.
Advantages are:
* The code is much shorter, and easier to understand.
* The previous code contained interpolation formulae for
  first-order 1d geodesic finite elements.  This restricted
  rod problems to first-order GFE.  A follow-up patch will
  allow higher-order approximations.
* The new code runs roughly twice as fast.

GeodesicFEAssembler can replace it without problems.

As a first step towards getting rid of the RodAssembler class,
this patch moves the getStrain, getStress, and getResultantForce
methods to the RodLocalStiffness class.  I am not 100% convinced
that that is the best place for them, but I can't think of a
better one right now.

ADOL-C implements most standard math functions for its
'adouble' type, and they are not in the namespace 'std'.
dune-fufem contains a file adolcnamespaceinjections.hh
which imports some of these methods into the 'std'
namespace, but that is not the proper way to do it.
Rather, they should be found by argument-dependent
lookup (ADL), that is

  using std::sin;
  auto v = sin(x);

When dune-curvedgeometry is not found, the normal Derivative is set to zero.

Use GFE::LocalEnergy, GFE::LocalIntegralEnergy, GFE::SumEnergy (and delete GFE::SumCosseratEnergy).

Add localintegralenergy.hh and neumannenergy.hh, they assemble the energy for a single element and work with a CompositeBasis

These classes work similarly to Dune::Elasticity::LocalIntegralEnergy and Dune::Elasticity::NeumannEnergy,
where the ones in Dune::Elasticity with a power basis (for the displacement function) and
Dune::GFE::LocalIntegralEnergy / Dune::GFE::NeumannEnergy work with a CompositeBasis (for the displacement AND the rotation),
so the indices to access the different parts of the basis are different.

Add sumenergy.hh, this class assembles the a sum of energies for a single element by summing up the energies of each GFE::LocalEnergy.

This class works similarly to the class Dune::Elasticity::SumEnergy, where Dune::Elasticity::SumEnergy extends
Dune::Elasticity::LocalEnergy and Dune::GFE::SumEnergy extends Dune::GFE::LocalEnergy.

    With this it will be possible to for the SumCosseratEnergy and the SurfaceCosseratEnergy
    to extend GFE::LocalEnergy, as they need multiple types of TargetSpaces.

Virtual Function is deprecated after dune 2.7.

Simon Praetorius' dune-vtk module has much better support for reading
and writing than my old hacks in dune-gfe.  Let's start adopting
dune-vtk for VTK I/O.

In this initial step, dune-vtk becomes a dependency of dune-gfe,
but only an optional one.  This may change.

Add a GeodesicFEAssemblerWrapper - it wraps a MixedGFEAssembler so it can be used like a GeodesicFEAssembler

The GeodesicFEAssemblerWrapper assembles the Gradient and the Hessian using the MixedGFEAssembler and then
resturctures them so they can be used with the normal RiemannianTRSolver.
This only works, if the FE spaces have the same order.

The GeodesicFEAssemblerWrapper needs to access the MatrixType.

Also adjust CosseratEnergyStiffness and MixedGFEAssembler for the use with a CompositeBasis instead of a PowerBasis

This makes it possible to use other Assemblers

This makes it possible to do parallel assembly

WHITESPACES: Wrap energy calculation and solve-call in the Mixed-Riemannian-TR solver in a try-catch statement

In case an error occurs while solving or calculating the energy, the program does not stop
but the error is handled in the Mixed-Riemannian-Trust-Region solver and the program continues
with a smaller trustregion-radius.

Apparently it is not used.

Add first version of the Riemannian Proximal Newton solver, as an alternative to the Trust-Region Solver.

In each step of these two iterative solvers, we try to find a correction
that decreases the energy of the nonlinear functional of the current iterate x.
The correction is calculated using the Taylor expansion around x,
resulting in the problem: Hessian(x) * correction = -gradient(x).
Within a certain radius around x, the functional can be approximated correctly and then
the corrections causes an energy decrease.
1) The trust-region algorithm ensures this using a trust-region.
2) The proximal newton method ensures this by punishing
   large corrections using a regularization factor.

In case the solve step (which is only done on process 0) goes wrong
communicate it to all processes.