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.

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);

Previously, the actual projection happened by calling the constructor
of one of the classes that implements points on a manifold.  This patch
introduces an new method projectOnto, which makes the projection more
explicit.

This is needed for the new gradientflow application.  The standard 'distance' method
doesn't cut it, because it is not differentiable near zero.  Therefore, even the
differentiable expression 'distance*distance' will fail to be differentiable for
an automatic-differentiation system.  I think in the long run we should replace
'distance' by 'distanceSquared' everywhere it is used.

Unfortunately, this patch is hacky: it only adds the method for the double/adouble
combination.

Which is the type returned by the derivativeOfProjection method.

[[Imported from SVN: r10067]]

This is needed for projection-based finite elements.

The code in this patch has not been tested yet.

[[Imported from SVN: r9887]]

[[Imported from SVN: r9886]]

[[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]]

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]]

[[Imported from SVN: r9449]]

[[Imported from SVN: r9448]]

I can't make up my mind whether I want 'ctype' or 'field_type'

[[Imported from SVN: r9447]]

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]]

[[Imported from SVN: r9397]]

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: r8369]]

It makes it difficult to be sure that an explicitly
requested type is really handed over to every place.

While we are at it: reverse the order of the template
parameters.  Now first comes the type, then the dimension.
This is more like FieldVector and friends, and hence
should be less confusing.

[[Imported from SVN: r8148]]

[[Imported from SVN: r8145]]

[[Imported from SVN: r8034]]

[[Imported from SVN: r7374]]

[[Imported from SVN: r7313]]

[[Imported from SVN: r7225]]

[[Imported from SVN: r7205]]

[[Imported from SVN: r7196]]

[[Imported from SVN: r7195]]

[[Imported from SVN: r7134]]

[[Imported from SVN: r7090]]

bugfix in thirdDerivativeOfDistanceSquaredWRTFirst1AndSecond2Argument.  Now it produces the same result as the fd approximation at least in for S^1

[[Imported from SVN: r7066]]

[[Imported from SVN: r7053]]

[[Imported from SVN: r7052]]

[[Imported from SVN: r7051]]

[[Imported from SVN: r7050]]

[[Imported from SVN: r7049]]