This removes one use of the CosseratEnergyLocalStiffness class,
which is scheduled for complete removal.

Energies of particular models should not implement external loads
themselves, because that would lead to a lot of code duplication
(and possible inconsistencies).  A one step towards that goal,
allow to construct a CosseratEnergyLocalStiffness object
without external loads.

Non-composite settings use Dune::Matrix<double>,
composite settings use a FieldMatrix where each entry
is Dune::Matrix<double>.

This is not quite as simple as the dune-functions convention,
which is to use Dune::Matrix in all cases.  But it is still
simpler than before.

There is no point in testing assemblers that only exist in the test
itself.  Historically, they may have been useful when developing
the dune-gfe assembler framework because they were simpler (they
compute the Euclidean derivatives, not the Riemannian ones).
Nowadays, they just waste CPU cycles.

This is what dune-function mandates.  We don't actually use
dune-functions here a lot, but it is still nice to stay in the spirit.
Also, I am thinking about using dune-functions bases for *some*
indexing work in the future.

Plus, I hope that getting rid of the blocking will improve run-times
of debug builds a little bit, in particular in the
LocalIntegralStiffness class.

This will later simplify merging the mixed and non-mixed versions
of the assembler code.

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 needed to actually compare the 3D-model with the 2D-approximation

Scalar bases used to work for that, but that feature got
removed a long time ago.

This is needed to test against the 2.6 core modules.

Using LocalIndexSet objects was mandatory with dune-functions-2.5
and earlier.  However, we only support 2.6 and later anyway,
so let's get rid of the backward-compatibility code.

That's already done in adolcnamespaceinjections.hh, in dune-fufem.

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.

Otherwise some dune-common stuff will not work properly,
for example copying of FieldMatrices that use adouble
as their number type.

In particular, assemblers now hand LocalView objects around, rather than pairs of
elements and LocalFiniteElements.

[[Imported from SVN: r9997]]

[[Imported from SVN: r9913]]

[[Imported from SVN: r9912]]

[[Imported from SVN: r9877]]

That should be no problem now that we use a 50-decimal digits type
for the FD approximation.

[[Imported from SVN: r9876]]