setupLaplacian: Add optional diagonal regularization

See merge request !539

This generalizes the necessary regularization for the umfpacktest and
makes it usable for other algorithms. A hint in Cholmodtest is added and
the other tests using this methods are kept unchanged.

The method was also cleaned up and modernized.

Co-authored-by: Santiago Ospina De Los Ríos <sospinar@gmail.com>

Move include of config.h from source to some header files

See merge request !566

[bugfix] Make solverfactory tests work without optional pkgs

Closes #117

See merge request !570

Tests failed in Suitspares or UMFPACK was not there.

Fix some issues found by Clazy, Cppcheck, and myself

See merge request !569

Use the left-hand side as a condition

It was removed 9 years ago.

Remove `isPublic` altogether.
Found by Cppcheck (variableScope).

Found by Cppcheck (unusedVariable).

Found by Cppcheck.

This is less about performance and mor about silencing
the Clazy warnings.
Found by Clazy (range-loop-reference)

Cleanup the VariableBlockVector implementation

See merge request !463

fix bvector += bindings

See merge request !565

Set real_type of MultiTypeBlockVector

See merge request !480

Revert "Merge branch 'issue/block-traits-field-traits' into 'master'"

See merge request !567

This reverts merge request !564

Define BlockTraits in terms of FieldTraits

See merge request !564

refactor blockvector bindings to allow for generic types

See merge request !562

Add a specialization of FieldTraits for VariableBlockVector

See merge request !563

[cleanup] Remove unused allocators

See merge request !560

Remove allocator template parameter from the classes
`base_array_unmanaged`, `compressed_base_array_unmanaged`,
`block_vector_unmanaged`, `compressed_block_vector_unmanaged`, and
`CompressedBlockVectorWindow`.
All of these classes do not manage memory on their own.
The provided allocator was only used to deduce `size_type`.
The latter is now provided as template parameter explicitely.

Notice that this (seemigly breaking) change is safe, because
all these classes are clearly marked as implementation details
that should not be used outside of dune-istl.