* Adjust to updated interface of `AffineConstraints`.
* Separate construction of constraints object from
  computation of its content.

Before the class only supported linear constraints.
By adding support for constant offsets, this can now
be used e.g. for hanging node constraints (linear),
Dirichlet constraints (constant), or both at once.

The algorithm basically interpolates fine DOFs from
coarse basis functions of neighboring elements. This
requires some mechanism to interpolate only hanging fine
DOFs and not all.
Instead of checking if the fine interpolation point is in
within the coarse element, we now check if the interpolated
DOF is associated to a subentity of the intersection.
In most cases this is equivalent. But for hierarchical bases,
the former does probably not lead to the desired result (*).

Remark: (*)
In principle one would expect that the conforming hierarchical
basis consists of the conforming P1-basis plus conforming bubbles.
This is the case for both algorithms (except for some numerical
issues for the old one). However, it turnes out that there are
different possibilities to define the conforming bubbles and
it's not clear which one is desired. Ideally we would like to have:

* The bubbles are lagrangian, i.e. each one is zero at the interpolation
  point of the other ones.
* The bubbles are non-negative.

For hanging nodes you can't have both at once. The old algorithm
guarantees the former, the new one the latter property. I'm undecides
which one is 'correct'.

This demonstrates the usage of hanging node.
So far the refinement indicator is a very crude
quick and dirty hack.

This adds a class `AffineConstraints` for storing contraints
for general dune-functions bases and a method
`makeContinuityConstraints()` for computing the
constraints for the H^1-conforming subspace
for classical FE spaces on grid with hanging nodes.

This is experimental and the interface may change.
Also some features are still missing:

* The code is generic and should work with nested
  bases and subspace bases. But this has not been
  tested so far.
* One may want to generalize `makeContinuityConstraints()`
  such that one can extend an existing constraints
  object. This way one could add constraints for
  different branches in the tree one after the other.
* Currently constraints are stored in a simple
  `std::unordered_map<std::map<Index,Coeff>>`
  data structure. Maybe this could be more efficient
  in a vector-based data structure or a sparse matrix.
  I had a compress method in mind that transforms into
  a more efficient storage once the contraints are fully
  build. But in my tests copying into a vector-bases
  data structure did not improve significantly, probably
  because the number of entries is relatively small.
* The constraints class is called `AffineConstraints`
  because it is intended to also hold Dirichlet constraints.
  This feature is currently missing.

Add utility functions for recursive traversal of matrices and vectors

See merge request !257

This has a few advantages:
* It does not require the basis just to do algebraic transformations.
* It is also correct if the pattern is not exactly the one given by
  the local basis coupling. This is e.g. important for hanging nodes.
* It is faster, because we loop over the matrix entries just once
  and in consecutive order.

This allows

```cpp
recursiveForEachMatrixEntry(matrix, [](auto&& matrix_ij, auto&& i, auto&& j) {
  ...
});

recursiveForEachVectorEntry(vector, [](auto&& vector_i, auto&& i) {
  ...
});
```

Here the container is traversed hierachically and the row and column multi-indices
`i` and `j` are instances of `Dune::Functions::StaticMultiIndex` with appropriate
length depending on the nesting depth.

[examples] Fix matrix/vector types of examples

See merge request !256

The nested matrix and vector types should correspond
to the index tree of the basis. Here, this is not the
case since `Field*<T,*>` was used instead of `T`.
While this is in many cases no problem, it may fail
if the matrix is recursively traversed with `IsNumber`
as termination criterion.

[cleanup] Remove experimental header arithmetic.hh

See merge request !255

This header was added a long time ago to replace `staticmatrixtools.hh`
and was later itself superseded by dune-matrix-vector. Furthermore there
was also a copy of this header in dune-solvers which was deprecated
since 8 years. The header is not used anywhere and is thus removed.
Since it was still documented as experimental, removal does not require
a deprecation here.

Improve performance of assembleGlobalBasisTransferMatrix

See merge request !254

To avoid duplicate work, `assembleGlobalBasisTransferMatrix()` used
a container to store all processed fine basis functions. The used
container is a `std::unordered_set<MultiIndex>`.

Unfortunately this container is really slow. With the improved
implemention it turned that checking, filling, clearning this
container is in fact more expensive and the assembly is faster
if the checks are removed. This is based on the test cases
of the corresponding test, that checks various combinations
of bases on 2d and 3d grids.

Using a suitable bit vector to store flags would indeed be faster.
However, it is very hard to derive a suitable container type
generically based on the current basis interface. (This will
hopefully iprove soon.)

The old approach used a `std::map` and compared coordinates
in the inner most loop to avoid duplicate evaluations
of `LocalBasis`. Instead the new approach determines the
interpolation points first and caches the values in advaced
based on the evaluation order. This improved the performance
significantly.

Make indentation consistent across header.
Adjust editor hints the indentation style.

[cleanup] Fix warnings

See merge request !253

Here the purpose of the loop is to do some operation several
times, but the operation does not depend on the loop variable
itself.

[examples] Add an example with a pure Neumann problem

See merge request !252

This is a small modification of the `poisson-pq2` example
where the boundary treatment has been removed. It's added
here to demonstrate how to conveniently add the kernel projection
to the iterative solver. Theoretically PCG is invariant under
contributions in the kernel, such that it is sufficient to
project the final solution. However, due to round-off errors
and the ill-conditioning of the matrix, these contribution
can be amplified on fine grids which severely slows down
the solver (e.g. about twice as many steps).

[examples] Add convenience utility for FastAMG preconditioner and use it in Poisson example

See merge request !249

* The way the `FastAMG` preconditioner is set up only works in 2.10.
* Using non-blocked matrices only works in master (>2.10) which is
  now tested as >=2.11, because in the 2.10 CI job, checking fo >2.10
  succeeds.

* Use logger to unify messages.
* Fix matrix and vector types (no nesting since we have flat indices).
* Use AMG instead of ILDL preconditioner if available.