Rather than just on the type for points in the domain.
The point type is not enough: For example, if the density involves
a coefficient function given as a GridView function, then the
density has to be able to bind the local coefficient function
to the correct element, for which it has to know the element type.

Integration domains can be elements (i.e., Codim<0>::Entity)
or Intersections.

The actual bind method will follow in a separate commit.

Currently, densities only get the type used for coordinates
of the integration domain.  However, this is not enough:
The complete domain must be known, and this domain can be either
a grid element or a grid intersection.

As a first small step, this patch introduces ElementOrIntersection
as a template parameter of the CosseratShellDensity class.

This is one step towards turning SurfaceCosseratEnergy into a
generic SurfaceIntegralEnergy class.

The compute-disc-error program reads this to compute discretization
errors.

Doing the data transfer via VTK files would be more convenient,
but that involves a resampling which I'd rather like to avoid.

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.

It is only used by `film-on-substrate.cc` which many people
do no use.

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

This should simplify the code, but it doesn't: Computing the
displacement still needs a lot of code lines.

Just like in cosserat-continuum.cc, there is now a Python class
that implements the initial iterate and the Dirichlet boundary values
at the same time.

This reflects better what the file does.

Rather than hardcoding a straight reference configuration

This is more flexible, and more consistent with what
cosserat-continuum.cc does.

That is simply more flexible than the old parametertree format.

It is required by dune-fufem anyway.

In particular, there is a directory dune/elasticy/densities now.

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.

dune-elasticity also has densities, but they implement a slightly
different interface.  Instead of having special code for such
densities in the LocalIntegralAssembler, add a wrapper that
makes densities from dune-elasticity look like dune-gfe densities.

There is no need to wrap the std::function that stores the
Neumann force density into a std::shared_ptr.