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 is what the master branch of the core modules currently
requires.

It was apparently not used.

If you should ever need something like this in the future,
please use periodicbasis.hh from dune-functions.

There are two important changes:  First of all, the new class implements
the `dune-functions` interface rather than the deprecated one based
on inheritance from `VirtualGridViewFunction`. Secondly, the new class
does not hard-wire geodesic interpolation anymore.  Rather, you can
give it interpolation classes which then govern how interpolation is done.

This change was long overdue.  It was now needed to make
gradient-flow.cc compile with the post 2.9 version of dune-fufem again.

This only works for gmsh-files with version 4 or 5, but this is what we want

Make GFE_ORDER and LFE_ORDER compiler macros and build the necessary combinations of cosserat-continuum-Xd-in-Xd

This triggers bugs in the Rotation and RigidBodyMotion classes.

In particular, it triggers what Jonathan Youett fixed in the
never-merged merge request

  !2

These bugs are fixed in this commit, too:
* The RigidBodyMotion class gets a `log` method
* The Rotation<3>::log method now returns EmbeddedTangentVector
  instead of TangentVector.

It was TangentVector whereas it should have been
EmbeddedTangentVector.

Calling log(a,b) returned a-b instead of b-a.

Also, enable unit tests for the RealTuple class.  The current test
will not trigger the bug in the log method: that will come shortly.

Finally, this commit is the first that mentions its user-facing
changes in the newly introduced CHANGELOG.md file.