... instead of binding to LocalFiniteElement objects.

This is how binding works everywhere else, too.  In addition,
in frees us from the difficult task to always get the
appropriate LocalFiniteElement objects to bind to.

Rather, expect them as constructor arguments.

As one further step towards making LocalInterpolationRules
more like (local) functions, introduce a new method 'bind'
accepting a local finite element and a set of (local)
coefficients.  This method replaces the constructor
taking the same arguments. Instead, the local function object
now has to be default constructed.  This is just an
intermediate step, however.

Previously, some code was in Dune::GFE, some was in Dune::,
and a lot of it was in the global namespace.

Previously, LocalEnergy would accept an arbitrary number of
template arguments, and (with the exception of the first one)
they would be interpreted as the factors of a product target space.
This patch replaces this template list by a single template
parameter, which has to be ProductManifold if a product space
is desired.

This has implications throughout the code.  In particular, there are
now two energy methods: One that still accepts coefficients sets
in the form

  std::vector<TargetSpace>

and a second one which accepts

  TupleVector<std::vector<Factors>...>

The second one really only makes sense for product manifolds.
However, as the 'energy' methods are pure virtual, they cannot be
disabled by SFINAE or C++20 concepts.  Therefore, the second 'energy'
method exists always, accepting

  TupleVector<std::vector<TargetSpace> >

if TargetSpace is not a product.

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.

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.

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.

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.

This used to work, because the matrix is 1x1 anyway (with corresponding
vectors), but some time ago the matrix and vector assignment
in dune-common was reworked, and now the code does not compile
anymore.

PQKNodalBasis has been renamed to PQkNodalBasis

[[Imported from SVN: r10101]]

[[Imported from SVN: r9978]]

[[Imported from SVN: r9977]]

This is now mandatory since Quaternions are not implicitly casted to Rotations
anymore (via Quaternion --> FieldVector<4> --> Rotation).  This implicit cast
lead to a nasty bug here, because it involved a normalization of the argument.

[[Imported from SVN: r8347]]

[[Imported from SVN: r8346]]

[[Imported from SVN: r8345]]

[[Imported from SVN: r8182]]

target space classes.  In particular, the coordinate type
now has to be given explicitly.

[[Imported from SVN: r8149]]