This fixed the following error when building with GCC 12.1.0-8 (Debian):

```
/src/dune-gfe/dune/gfe/rotation.hh:225:42: error: invalid declarator before 'axis'
  225 |     Rotation<T,3>(Dune::FieldVector<T,3> axis, T angle)
      |                                          ^~~~
/src/dune-gfe/dune/gfe/rotation.hh:225:41: error: expected ')' before 'axis'
  225 |     Rotation<T,3>(Dune::FieldVector<T,3> axis, T angle)
      |                  ~                      ^~~~~
      |                                         )
```

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.

The tests failed since the construction of values of ProductManifold<> in ValueFactory uses random entries between [0.9..1.1]. These are then used for the tests and are projected onto the manifold. 

To pass this tests it is needed to adjust several Taylor expansions and thresholds. For example this commit increases the threshold from `1e-4` to `1e-2` and adds more terms to the Taylor expansion. The reason for this change is explained in the following. 

The problem is, even if the tolerance `1e-4` is sufficient to have a correct function value within machine precision, it is not always sufficient to get correct derivatives since here we lose orders of correctness.

For  example of for sinc(x) we need to put the threshold at `1e-4` to get the correct function value if we use  `1.0-x*x/6.0` as approximation formula.

If we then use this formula within automatic differentiation or finite differences, e.g. the derivative algorithms  "sees" only the following formulas of the first and second derivative:

- Function value: `1.0-x*x/6.0`   This function is implemented
- First deriv: `-x/3.0`      This sees the derivative algorithms as first derivative
- Second: `-1.0/3.0`       This sees the derivative algorithms as second derivative

Obviously, this is the case if the function value is inside the region where the Taylor expansion is used.

If we use these functions to test the exactness of the derivatives we need to set the threshold to `x<1e-6` to get exact second order derivatives where the error is within machine precision. Therefore, for larger values `x>1e-6` the exact formula has to be used to get correct results. Unfortunately, in this range the exact derivative are already unstable.
E.g. the first derivative formula behaves already strange near `x=1e-4`.

Therefore,
to get a correct derivative value we need to switch to the Taylor expansion earlier (`1e-4`) to prevent using the unstable exact formula. But in this range the Taylor expansion is unable to reproduce an approximation error within machine precision.

I think the only way to fix this problem is to add more terms to the Taylor expansions. Since even if they seem to be sufficient in terms of function value, usually they are not sufficient in terms of derivatives.

For `sin(x)/x` a test ist at https://godbolt.org/z/T995hGec3 and for `acos(x)^2` https://godbolt.org/z/TG9E15jjf.

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.

ADOL-C implements most standard math functions for its
'adouble' type, and they are not in the namespace 'std'.
dune-fufem contains a file adolcnamespaceinjections.hh
which imports some of these methods into the 'std'
namespace, but that is not the proper way to do it.
Rather, they should be found by argument-dependent
lookup (ADL), that is

  using std::sin;
  auto v = sin(x);

Because it really is a functionality of rotation matrices in quaternion
representation.  Only the Cosserat energies use it at the moment, but
this is coincidental.

In the same process, the method is renamed to quaternionTangentToMatrixTangent.
That seems to be a more telling name.

Assignment from initializer lists makes this much shorter.

WARNING: These methods implement the projection in quaternion
space.  This is NOT the canonical projection in matrix space.

This is necessary to compute H1 errors in matrix space.

When switching to the double covered quaternion pair, the
corresponding distance was not computed correctly

Needed for projection-based finite elements.

This patch also adds a unit test.  So far this test passes.

This fixes a dubious compiler error.

[[Imported from SVN: r9871]]

[[Imported from SVN: r9846]]

[[Imported from SVN: r9845]]

[[Imported from SVN: r9588]]

We normalize unit vectors again in the constructor and the assignment operator.
This makes sure we never drift away from the unit sphere, and it also allows
us to init unit spheres with any value in R^n and be sure we obtain a unit
vector.  This makes the test pass again.  Leaving the projection out didn't
really make a measurable difference anyway.

[[Imported from SVN: r9574]]

The old implementation used quaternion multiplication to transport
the argument to the Lie algebra, and use the standard formula there.
However, one may as well use the formula for the unit sphere in R^4,
which is much simpler, and also faster.  I fact, this patch gives
a few percent of speedup for the overall code.

[[Imported from SVN: r9562]]

There is one copy which takes FieldVector<T,4> as its second argument.
Since EmbeddedTangentVector ( = Quaternion<T>) derives from FieldVector<T,4>,
that second implementation should work in all cases.

[[Imported from SVN: r9560]]

The methods 

Rotation<T,3> exp(const Rotation<T,3>& p, const EmbeddedTangentVector& v) 

and

otation<T,3> exp(const Rotation<T,3>& p, const Dune::FieldVector<T,4>& v)

do literally the same.  So they should be next to each other in the code.

[[Imported from SVN: r9559]]

This effectively means that we use another prolongation of the distance 
function on M into the surrounding space.  Since the prolongation does not
matter this patch should not change the algorithm behavior.  However, it
shaves off a few norm calculations and division.  I cannot really measure
any difference though.

A possible effect of this is that while all values should remain on the
manifold, they may start to 'drift away' due to numerical artifacts.
So we may have to add an occasional renormalization step eventually.

[[Imported from SVN: r9558]]

When using the classes with ADOL-C, T becomes an 'adouble',
which is a non-trivial type.  However, the convexityField
is constexpr (and with a reason -- otherwise we could write
the initialization together with the declaration), and
constexpr and non-trivial types don't work together.

[[Imported from SVN: r9444]]

Because ADOL-C doesn't like calls to sqrt(0), obviously.
The use of sqrt(x) for small x can be avoided completely
using modified series expansions, because the overall
function exp is differentiable even at x=0.

[[Imported from SVN: r9426]]

Makes for a more precise Hessian matrix when using automatic differentiation.

[[Imported from SVN: r9425]]

[[Imported from SVN: r9424]]

Because ADOL-C cannot handle the latter

[[Imported from SVN: r9386]]

[[Imported from SVN: r9385]]

[[Imported from SVN: r9384]]

And use it in the test.

This patch uses the new 'constexpr' macro.  Hence it is C++11 only.

[[Imported from SVN: r9195]]

[[Imported from SVN: r8972]]

with respect to the quaternion coordinates.  Or, in other words,
the second derivative of the map from quaternions to 
orthogonal matrices.

[[Imported from SVN: r8407]]

New implementation properly handles the two sheets.

Now the TargetSpace test passes again.  Yay!

[[Imported from SVN: r8375]]

The new implementation should take proper care of the two-sheet structure.

I am writing 'should' here: it still fails the test sometimes,
but then the result appears to be close enough to think rounding errors
are responsible.

[[Imported from SVN: r8373]]

The new implementation properly handles the double-sheet structure

[[Imported from SVN: r8372]]