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

Both classes are meant to do the same thing.

This makes the interface more consistent.

These two exist in base classes, and they are inherited anyway.

ADOL-C can compute all derivatives with two different modes:
scalar- and vector mode.  In theory they should produce exactly
the same results, but sometimes there are bugs (I have found
a few of those myself).  adolctest-scalar-and-vector-mode tested
whether the two modes produced the same result for a particular
Cosserat configuration.

I do not think that dune-gfe is the right place for such a test.
It tests for bugs in ADOL-C itself, and that is the job of
ADOL-C's own test suite.  Consequently, I am removing the test.

This allows to get rid of a lot of (all) multiple inheritance.

Previously, LocalEnergy would accept an arbitrary number of
template arguments, and (with the exception of the first one)
they would be interpreted as the factors of a product target space.
This patch replaces this template list by a single template
parameter, which has to be ProductManifold if a product space
is desired.

This has implications throughout the code.  In particular, there are
now two energy methods: One that still accepts coefficients sets
in the form

  std::vector<TargetSpace>

and a second one which accepts

  TupleVector<std::vector<Factors>...>

The second one really only makes sense for product manifolds.
However, as the 'energy' methods are pure virtual, they cannot be
disabled by SFINAE or C++20 concepts.  Therefore, the second 'energy'
method exists always, accepting

  TupleVector<std::vector<TargetSpace> >

if TargetSpace is not a product.

In the long run this is cleaner than setting up the type in
the LocalStiffness class itself.

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

The rest of the HarmonicEnergy class is now independent of
the density.  It is functionally equivalent to the LocalIntegralEnergy
class, and shall be replaced by that eventually.  However,
LocalIntegralEnergy still has the deformation/rotation-split
hard-coded in a few places, and that needs more work.

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

Currently, Cosserat materials are hard-wired in the interface.
This patch changes the interface a little bit towards being
more general.

That's another step closer towards merging the
MixedLocalGeodesicFEStiffness and the LocalGeodesicFEStiffness.
Also, it is necessary to be later able to generalize the code
for product spaces with more than two factors.

It is deprecated, and not used anymore.

... rather than two separate spaces.  This is one step towards
getting rid of it altogether.

... regarding ambiguous logical expressions.

Replace RigidBodyMotion by ProductManifold

See merge request !141

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.

It contained code for mixed-dimensional domain decomposition algorithms
involving Cosserat materials.  This code has moved to a separate modul
'dune-gfe-coupling' a long time ago, and it is not used from anywhere
else in dune-gfe.

Add a CI job that runs uncrustify and checks for modifications

See merge request !140

If modifications are found this means that the style rules
are violated.

The uncrustify configuration file is the one from

  https://dune-project.org/share/dune-uncrustify.cfg

downloaded on Jan 5. 2024.

Various minor improvements

See merge request !139

They should be installed, but since dune-gfe doesn't have any
downstream dependencies, nobody has missed the files yet.

It was essentially a reimplementation of Rotation::orthonormalFrame,
just with a different interface.  It was not directly used by any
code.

Reenable cosseratrodtest

See merge request !127

Previously, the test mysteriously failed on the CI system, but not locally.
I recently tried again and the CI test passed again.  I don't understand
what was going on, but for the time being let's enable the test again.