Previously, the writer requested an FE basis to represent the director
vectors.  With the help of ComposedGridViewFunction this patch allows
to avoid this extra basis, which makes for a much nicer interface
for CosseratVTKWriter.

The NonplanarCosseratShellEnergy class contains a reimplementation of
the energy density of CosseratShellDensity.  The code is much easier
to understand and maintain if the density implementation of
CosseratShellDensity is used instead.

For some reason there were two code paths for the creation of the
solver object: One for dim==dimworld, and one for dim!=dimworld.
These shouldn't really differ, though, and indeed they didn't
as far as I can tell.  Theremore, merge the two code paths.

That is one step towards splitting off the energy density
into a separate class.

Also, it helps to unify the code paths for the different grid dimensions
in cosserat-continuum.cc

And use it in the dim==dimworld part of cosserat-continuum.cc.

In the code that takes the initial iterate from a while, a call
to 'interpolate' was out-commented, because interpolating an
'EmbeddedGlobalGFEFunction' was not possible back in the days.

That has changed so, and 'interpolate' can now be called.
I still doubt that the code ever worked or works now.
How could it ever be tested?

'#	geändert:       src/cosserat-continuum.cc

It is required by dune-fufem anyway.

Instead, use LocalIntegralEnergy and the newly introduced densities
for bulk models or planar shell models.

While doing so, give an error message when non-trivial volume loads
are requested.  I have no example file that actually uses them
at the moment, and just by looking at the code I find it hard to believe
that they actually worked.  Getting them to work will mean having
introduce a density for volume loads, which don't want to do
until I need them.

Since this is the last use of the CosseratEnergyLocalStiffness class,
this patch remove the entire class as well.

That way, we can also set the initial microrotation -- previously
it was hard-wired to the identity matrix.

Being able to explicitly choose the initial microrotation allows
to start, in particular, from a twisted strip.

Previously, the method basically hand-implemented a writer for
VTK files.  Using dune-vtk instead leads to much shorter and
simpler code, and gives us access to all the dune-vtk niceties,
like binary files and high-order grid cells.

Rather than the grid itself.  Because the grid view is all that
a writer needs to know about.

That way, a single Python file is enough to describe the entire
boundary value problem.

Rather than as our homegrown .parset.  That way, after more changes
this will allow to have the entire problem description in a single
file, including the boundary data.

They were expected to be the factors of a ProductManifold which is
also a template parameter.

Expecting the product and the factors is redundant.  We simply
extract the factors from the product now.

Previously, it expected two factor spaces, as separate template
parameters.  Taking a single ProductManifold type is more consistent
with GeodesicFEAssembler, and it allows to eventually generalize
the code to more factors, if desired.

... but disallow a plain pointer.  This increases consistency with the
GeodesicFEAssembler class.

They do the same thing, essentially.

This is what the non-mixed ADOL-C assembler does, and I want to
merge the two.

The new method is Fufem::markBoundaryPatchDofs, which apparently
works in just the same way.

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.

In particular:
- Use the CosseratVTKWriter also for MIXED_SPACE = 1, only print out the deformation though
- Use a SubsamplingVTKWriter only for dim==gridDim==3

Use the grid function provided by the gmsh4-reader as the stressfreegridfunction in nonplanarcosseratshellenergy

This only works for gmsh-files with version 4 or 5, but this is what we want

Add option to define deformation Dirichlet values for each direction separately in cosserat-continuum

Make GFE_ORDER and LFE_ORDER compiler macros and build the necessary combinations of cosserat-continuum-Xd-in-Xd