In detail we can now call the following free functions using objects
of type P[1,2]VectorFunction
- createVectorFromFunction()
- createFunctionFromVector()
- applyDirichletBC()

Commit also adds a simple VectorFunctionPetscTest that checks that
conversion to and from works.

We also rename the first argument of createFunctionFromVector() in
PETScVector from src to dst, as this seems more self-explanatory.

The new classes are children of the VectorToVectorOperator and called
1. P2ConstantEpsilonOperator
2. P2ElementwiseAffineEpsilonOperator
3. P2ElementwiseBlendingEpsilonOperator

Operator 1 uses the FEniCS forms p2_(tet_)stokes_epsilon(_tet) while
the other use corresponding HyTeG forms. These are the var variants
and, thus, need a callback function for the variable vicosity. This
is to be passed to the constructor of the operators. They will use
it to generate objects for the sub-forms and pass them to the
constructors of their Elementwise sub-operators.

Additionally commit implements a P2ConstantFullViscousOperator.
The latter is based on FEniCS forms. So it does support neither
blending nor variable viscosity.

Adds a ViscousOperatorsTest that checks generation of objects of the
four new operator types for a 2D and a 3D setting.

The commit adds a GenericOperator and an OperatorWrapper class. The
approach is the same as with wrapping functions for the BlockFunction
class. We also add a basic setup and apply test.

The commit adds an CSFVectorFunction::interpolate() method that accepts
a BoundaryUID. It also adds a test to the test suite for checking that
setting and usage of BoundaryUIDs works as expected.

start implementatin of a meshinfo that coarsens a given meshinfo which can be used as a new coarse mesh

[WIP] Added mesh generator for Tokamak-like mesh and started working on blending function to map to actual geometry.

Commit introduces two children of VectorToVectorOperator. These are
 - VectorLaplaceOperator
 - VectorMassOperator
The two classes are templated and we instantiate various P1 and P2 flavors
of the two operators.

VectorOperatorBasicTest checks that we can compile them and call apply().

Commit extends the test to run also basic testing for P1VectorFunctions
and renames it to VectorFunctionBasicTest.

Changed CMakeLists.txt to run certain tests not only in Release mode but also when built with DebugOptimized or RelWithDebugInfo to better reflect actual test coverage in coverage job.

Implemented linear, 2D benchmark of Popov et al. (2014) to test variable viscosity Stokes operator for P1-P1-stab and P2-P1.

Tests and PETSc block-preconditioner integration for 3D epsilon Stokes operator, P1-P1-stab and P2-P1

The idea of this function is to return for a given operator
the number of couplings between degrees of freedom. Modulo
elimination of Dirichlet boundary conditions and zero coupling
weights this will correspond to the number of non-zeros in
the sparsity pattern of the associated matrix.

Note that the coupling counts will only depend on the function
spaces involved, but not on the specifics of the operator resp.
bilinear form.

Thus, getNumberOfDoFCouplings() is a driver that in turn relies
on the actual counting being done in the countLocalDoFCouplings()
function. Its purpose is mostly to determine from the operator
the underlying sub-operators and function spaces.

This commit implements the functionality for 2D and for
P1Operators in 3D.

Further work on coupling count

- 2D case works now for P1-P1 for the "All" case
- In 3D the results are incorrect
- Started adding BC stuff, but will remove that again, as it get's
  too complicated; we would need to discard not only the to but also
  the from couplings on those primivites.

Coupling count now works also for scalar P2 operators in 2D

* Implemented the basic VertexDoFFunction and EdgeDoFFunction combos as
  building blocks.
* Removed all boundary condition stuff.

Makes getNumberOfGlobalDoFCouplings() a free-function

The reason for this is that inside the Operator class we do not have
enough information to compute the number of couplings for block operators
such as Stokes. For those cases it is not only the supports of the
ansatz functions that determine the number of couplings, but also the
block structure of the operator itself.

CouplingCountTest now also works for P2-P1Taylor-Hood-Stokes operators
in 2D.

Fixes problem with CouplingCountTest when building w/o PETSc

Completes implementation of countLocalDoFCouplings for P1Functions in 3D

The CouplingCountTest now runs through for a P1Operator on the 3D mesh
pyramid_4el.msh. Thanks to Nils for pointing out to use getLocalEdgeID()
to get the edge into cell couplings right.

As we now have P[12]VectorFunction objects available we should IMHO make
more use of those to reduce code complexity in the solvers. This commit
adds the following four new templated operators:

- P1VectorToP1ScalarOperator  (-> divergence = div)
- P1ScalarToP1VectorOperator  (-> gradient = divT)
- P2VectorToP1ScalarOperator  (-> divergence = div)
- P1ScalarToP2VectorOperator  (-> gradient = divT)

As an example in P2VectorToP1ScalarOperator.hpp we typedef three
divergence operators

- P2ToP1ConstantDivOperator
- P2ToP1VariableDivOperator
- P2ToP1ElementwiseBlendingDivOperator

The divergence operators get tested in a new DivergenceOperatorTest.

P2ToP1ConstantDivOperator is used to replace some lines of code in
the computations in StokesPCGSolverOld.

For those operators that have no 3D implementation available, e.g.
there is no P2ToP1BlendingDivzOperator, we also add the two dummy
operators

- P2ToP1DummyOperator
- P1ToP2DummyOperator

The P2P1TaylorHoodStokesOperator and P1StokesOperator receive
corresponding div and divT members. This currently is in addition
to the div_x etc. members.

This is the second step of refactoring the VTKOutput class. When
P[12]VectorFunctions are added to the dataexport, those now get
written as vector fields.

Commit also adds a basic functionality test for the VTKOutput class.

Test demonstrates that P2VectorFunction::prolongate and restrict were
not instantiated before, because requesting this causes a compiler
error, because delegation to the underlying P2Function(s) fails, as
these do not implement these methods.

RowSumTests.cpp now called RowSumTest.cpp [same with test names]

The new class constitutes an operator that is, in a matrix sense, diagonal
and where the diagonal values may change from DoF to DoF. An example would
be a lumped mass matrix on a blended domain.

The operator wraps itself around an ElementwiseOperator and uses the latter
to assemble and obtain the diagonal values. The DiagonalNonConstantOperator
is intended to work together with RowSumForms, but will work for any other
form, too, by just disregarding the non-diagonal matrix entries.

While currently combined with an underlying ElementwiseOperator the
DiagonalNonConstantOperator could also be combined with any other operator,
as long as that provides access to the diagonal matrix entries in the form
of a HyTeG function.

Commit adds a P1RowSumForm which is a child of the P1Form. Same as with
the P2RowSumForm. The P1RowSumForm lumps the weights of a P1Form onto
the diagonal.

In order to make it usable with P1HyTeGForms the commit also makes the
latter a child of the P1Form. Something we did not do so far, because
our form stuff is not too consistent currently w.r.t. all the different
integrate() variants and the fact that we have the generated HyTeG forms
which so far only work for 2D and the "manual" HyTeG forms that for P1
elements are partially 3D only, while the P2 HyTeG forms cover 2D and 3D.

The RowSumFormTests now include the P1RowSumForm using the same
P1FenicsForms as the test for P2.

Note that the P1RowSumForm is not really needed for the P1FenicsForms
as the P1ConstantOperator inherently implements lumping by itself.

Commit makes the test code more generic so that we will then be able
to re-use it to test a future P1RowSumForm, too.