The current implementation assign one degree of freedom to each
element, regardless of its type.  That only works for quad grids:
We are implementing Lagrange FE here, and these don't assign
degrees of freedom to triangles.

'Only' a stupid typo: '=' instead of '+='.

As of version 2.6, dune-functions doesn't properly do interpolation
of vector-valued functions with scalar-valued bases anymore.

The code it contains is adolcnamespaceinjections.hh.

I found those wrong types when trying to use a HarmonicEnergyStiffness
with a RigidBodyMotion.

In this case, two different refinements of the grids are not
necessarily geometrically identical.  This means we cannot
use hierarchic search with the global position of a quadrature
point, and expect to find the point on the other grid as well.

Instead, we go done to the coarsest grid, and make the transfer
to the other grid there.

Capturing any polymorphic object by value is wrong,
and gcc 8 started to warn about this in the case
of exceptions.

The latter is deprecated as of dune-functions 2.6.

It's the same code, but the old name is deprecated.

Running the test aborts with an error, because the error is exactly
the same as before this patch.

It is not actually used.

This is needed to build with a recent dune-common and dune-fufem

The main reason for this is that it is apparently needed for situations
where the grid dimension is not the world dimension.  It is a bit
shorter two.  I was hoping that it would also be faster, because we
eliminate an intermediate matrix object.  However, preliminary tests
have not shown any differences.

This makes the test build again.

It also removes the FD test for the gradient of the harmonic energy.
Since the HarmonicEnergyStiffness class does not implement the
gradient anymore, there is nothing to test here.

Previously, the error norms where computed in the respective global
embedding space of the TargetSpace.  For the case of Rotation<3>
this was the space of quaternions, because this is how the
Rotation class is implemented.  However, this does not lead to
correct results.  Therefore, this patch adds special handling
for Rotation<3>, and computes the errors norms in the space of
3x3 matrices.

The CI system found this for me, because it only goes wrong
when dune-foamgrid is not available.

The interface of Solvers::IterativeSolver used to make its
iterationStep_ member publicly available.  This has changed,
and the iteration step can now only be accessed by a getter
method (which is good).  However, that getter returns a
reference, but not the full smart pointer.

See the discussion at

  https://git.imp.fu-berlin.de/agnumpde/dune-solvers/merge_requests/23

In theory this is dangerous, because a pure Newton method will
only converge locally.  However, the trust-region part had been
partially disabled anyway, and I have not noticed any problems.
Also, I think that from my well-posedness result for higher-order
GeoFEs follows that a Newton method will always converge if the
problem is well-posed (that is how the proof works, after all).

On the plus side, this patch brings roughly 5% speed increas.