... by LagrangeLocalFiniteElementCache.

It run-time fails on the CI system for unknown reasons.
I don't currently have the time to spend more time debugging this.
Therefore, this patch simply disables the test and leaves a note.

Currently this test fails on the CI system with an obscure message
about not being able to write the tape to a file.  Maybe reducing
the complexity of the functional (by reducing the FE order) will
get us around that.  In any case I think testing with first-order FE
is just as thorough as with second-order ones.

This is needed to actually compare the 3D-model with the 2D-approximation

In particular:
* Forward declaring ProductManifold in the `impl` namespace
  is not a good idea.
* Add missing headers

targetspacetest.cc is extended to test for the first issue.

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.

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.

This involves fixing the secondDerivativeOfDistanceSquaredWRTSecondArgument
method: Previously it returned a FieldMatrix, but the test requires
a SymmetricMatrix.

Move the polar decomposition to a separate file and add the algorithm by Higham and Noferini (from Robin Fraenzel)

In the test for the Higham and Noferini algorithm, we see:
Unfortunately, for matrices that are close to an orthogonal matrix, this algorithm is
about 2x slower. One can benefit from the Higham and Noferini algorithm only if the
matrix is quite far away from an orthogonal one.

Use correct vector type for the combination of displacement and rotation in geodesicfeassemblerwrappertest

Add a simple test with a grid containing one element testing if the energy is invariant of the number of grid refinements.

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.

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.

GeodesicFEAssembler can replace it without problems.