Divide the regularization parameter through the scaling parameter in the PN solver instead of multiplying

In the PN solver, we add identity*regularization/scaling to the stiffness matrix.
This has two effects:
- make the system matrix positive definite
- penalize large corrections to ensure an energy decrease in each step

The regularization parameter is adapted if either the system matrix is not positive definite
if there is an energy increase. This works similar to the trust-region radius in the TR solver.
The correction must be inside the trust-region, this ensures there is an energy decrease
in each step.
For each component of the correction, the trust-region radius as well as the regularization parameter
is multiplied with a scaling factor, because the correction for the displacement works depends
on the grid size where the correction for the rotation does not.

To align the effect of the scaling parameter, we need to divide through the scaling parameter in
the PN solver and multiply with it it in the TR solver.

... by LagrangeLocalFiniteElementCache.

It was apparently not used.

If you should ever need something like this in the future,
please use periodicbasis.hh from dune-functions.

This used to work A Long Time Ago, but the feature was removed
eventually.  Unfortunately, the code still used to build,
but failed to produce the correct result.  More recently,
some other commit in dune-functions apparently now leads to
a build failure when trying to call 'interpolate' for a
vector-valued function and a scalar basis.  This is nice!
It allows to catch errors earlier.

The old style has been deprecated for a long time, and is not
supported by dune-fufem anymore.

(In particular, the code discretizationerror.hh now requires
functions to satisfy the dune-functions function interface.)

In the wake of this, compute-disc-error.cc gets a number
of changes.  Let's hope I didn't screw up anything.

There are two important changes:  First of all, the new class implements
the `dune-functions` interface rather than the deprecated one based
on inheritance from `VirtualGridViewFunction`. Secondly, the new class
does not hard-wire geodesic interpolation anymore.  Rather, you can
give it interpolation classes which then govern how interpolation is done.

This change was long overdue.  It was now needed to make
gradient-flow.cc compile with the post 2.9 version of dune-fufem again.

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

The multiplication by operator* between a ScaledIdentityMatrix
and a FieldMatrix only got introduced in Dune 2.9.  Therefore,
avoid it if we are building with earlier versions of Dune.

To build these combinations with the CI-system, install foamgrid for the tests with parmg, vtk, curvedgeometry and curvedgrid

This is needed to actually compare the 3D-model with the 2D-approximation

Deprecate the call to energy with a RigidBodyMotion in cosseratenergystiffness and in nonplanarcosseratenergystiffness - this is actually duplicate code!

They can't be removed yet because they are still used in tests though!

Correct the stopping criterion in the Riemannian-TR-Solver, Riemannian-PN-Solver and MixedRiemannian-TR-Solver

Do not stop if the correction gets small because the trust region radius gets small or the regularization parameter gets large

In particular:
* add flag "useAlternativeEnergyWCoss" to NonplanarCosseratShellEnergy
* if the flag set to true, the model from the paper "Alternative derivation of the higher-order constitudtive model for six-parameter elastic shells", equations (119) and (126) is used

In particular:
* Forward declaring ProductManifold in the `impl` namespace
  is not a good idea.
* Add missing headers

targetspacetest.cc is extended to test for the first issue.

Using FieldMatrix<,1,1> for scalars has been the standard Dune way
for a long time, but since dune 2.7 using scalars directly works
just as well.

They are getting removed now for good after the release of
dune-fufem 2.9.  The code that replaces them has been there
for quite a while, and therefore we can simply use it
without having to worry about compatibility with older
dune-fufem versions.