Also remove dune-cuvedgeometry as it is a dependency of dune-curvedgrid

This has been changed to Dune::Vtk::FormatTypes::ASCII in the dune-vtk module

System test for the Cosserat rod problem

See merge request !75

The previous implementation worked only for first-order finite element
spaces, because it assumed that grid vertices and Lagrange nodes
were identical.

This test assembles and solves a prototype Cosserat problem.
In then checks whether the required number of iterations and the
final energy match given (hard-coded) values.

Feature/stress plot

See merge request !73

Remove support for Dune 2.6 and older

See merge request !74

Small change/fix in Mixed Riemanian Trust region solver

See merge request !69

Modernize rod code

See merge request !67

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

This reflect the current purpose of the test much better.

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.

This is a prerequisite to a) support for higher-order FE,
and b) getting rid of the hand-written CosseratVTKWriter.

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);

fixed mixed riemanniansolver issues

See merge request !68

Feature/remove vertex normals

See merge request !63

In the 'mixed' case the volume term was simply forgotten, and not
actually handed to the assembler.

It is very unlikely that somebody will use that ever again.

Rather than using a default file, which was the case previously.

Otherwise the program aborts for the usual mysterious reasons.