The compute-disc-error program reads this to compute discretization
errors.

Doing the data transfer via VTK files would be more convenient,
but that involves a resampling which I'd rather like to avoid.

Previously, the writer requested an FE basis to represent the director
vectors.  With the help of ComposedGridViewFunction this patch allows
to avoid this extra basis, which makes for a much nicer interface
for CosseratVTKWriter.

This should simplify the code, but it doesn't: Computing the
displacement still needs a lot of code lines.

Just like in cosserat-continuum.cc, there is now a Python class
that implements the initial iterate and the Dirichlet boundary values
at the same time.

This reflects better what the file does.

Rather than hardcoding a straight reference configuration

This is more flexible, and more consistent with what
cosserat-continuum.cc does.

That is simply more flexible than the old parametertree format.

It is required by dune-fufem anyway.

Rather than the grid itself.  Because the grid view is all that
a writer needs to know about.

The new method is Fufem::markBoundaryPatchDofs, which apparently
works in just the same way.

The ProductManifold class generalizes RigidBodyMotion, and can do
everything that the RigidBodyMotion class can.  Therefore there is
no point in keeping RigidBodyMotion any longer.  Having two
implementations for the same thing will just confuse people.

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

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

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.

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.

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.

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

[[Imported from SVN: r9982]]

[[Imported from SVN: r9616]]

[[Imported from SVN: r9614]]

[[Imported from SVN: r9579]]