This is the basis used as interpolation weights (for geodesic
FE functions) or for interpolating in the embedding space
(for projection-based FE functions).  The basis is not actually
used yet, but it needs to be given to the class in the
constructor.

Rather, expect them as constructor arguments.

Instead, expect to be given one from the outside.  This is one
more step towards making local interpolation rules more like
local functions.

There is a generic mechanism for surface loads in form of the
NeumannEnergy class (to be replaced soon(TM) by something
even more generic).  This is what should be used, instead
of ad hoc implementations such as the one in SimoFoxEnergy.

Rather than a LocalFiniteElement.  This makes LocalGeodesicFEFunction
more like a dune-functions-style local function, which I think
it should be.

Rather than a LocalFiniteElement.  This makes LocalGeodesicFEFunction
more like a dune-functions-style local function, which I think
it should be.

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

I wrote them years ago mainly because I thought they should exist.
But they were never actually used them for anything, and I don't
really know were they could be used either.  Supposedly they
could be useful for implementing problems without a minimization
formulation, but that's not currently planned, and I don't know
what the precise requirements would be, either.

Since the code is short and almost trivial, and easily resurrected,
this commit removes the two files.  For newcomers this will mean
two less files to wonder about.

It is default-implemented in LocalDensity itself, and therefore
density implementations don't have to implement it themselves
unless they need to do something nonstandard.

Rather than just on the type for points in the domain.
The point type is not enough: For example, if the density involves
a coefficient function given as a GridView function, then the
density has to be able to bind the local coefficient function
to the correct element, for which it has to know the element type.

Integration domains can be elements (i.e., Codim<0>::Entity)
or Intersections.

The actual bind method will follow in a separate commit.

It is only used by `film-on-substrate.cc` which many people
do no use.

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.

The BulkCosseratDensity class implements three types of curvature
tensors. Previously, the preprocessor was used to select the one
to be actually used.  This patches removes the preprocessors checks
and implements run-time switches instead.

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.