Based on the intial implementation by Oliver Sander (see !168)

Merge branch 'feature/cleanup_preconditioner_configs' into 'master'

ref:core/dune-istl\>

### Summary

This MR adds missing documentation for ParameterTree arguments and replaces
repeated constructors by delegating constructors.

See merge request [core/dune-istl!379]

  [core/dune-istl!379]: gitlab.dune-project.org/core/dune-istl/merge_requests/379

Merge branch 'issue/fcg_solver_constructor' into 'master'

ref:core/dune-istl\>

### Summary

Add missing constructor (with operator, precon, and parameter-tree) to
RestartedFCGSolver

### Details

The constructor with operator, precon, and parameter-tree, but without
scalar-product was just missing and is added by this MR for consistency with
all the other iterative solvers.

See merge request [core/dune-istl!378]

  [core/dune-istl!378]: gitlab.dune-project.org/core/dune-istl/merge_requests/378

Merge branch 'feature/direct_solver_constructors' into 'master'

ref:core/dune-istl\>

### Summary

Add ParameterTree constructors for direct solvers

### Details

To be consistent with other linear solvers, a constructor with a ParameterTree
argument is added to all direct solvers. Mostly the verbosity level is read
from the configuration, but SuperLU also reads the *reuseVector* parameter.

See merge request [core/dune-istl!377]

  [core/dune-istl!377]: gitlab.dune-project.org/core/dune-istl/merge_requests/377

Merge branch 'feature/replace-ifelse' into 'master'

See merge request [core/dune-istl!376]

  [core/dune-istl!376]: Nonecore/dune-istl/merge_requests/376

Merge branch 'bugfix/MissingAppend' into 'master'

See merge request [core/dune-istl!374]

  [core/dune-istl!374]: Nonecore/dune-istl/merge_requests/374

Merge branch 'explain-implicit-buildmode' into 'master'

ref:core/dune-istl\> Circumstances forced me to finally learn what the
BCRSMatrix 'implicit' build mode really does, and where its limitations come
from. I had to read the code for that. As it turns out, the documentation of
the mode is quite misleading. My main gripe is that the code uses two
different auxiliary data structures, but the documentation calls them both
'overflow'. This problem even extends to the variable naming in the code.
Behold: the parameter 'overflowsize' is NOT the size of the member 'overflow'.
It doesn't even have anything to do with that member\...

To improve the situation, this patch does three things:

1.  It rewrites the documentation. In particular, the 'overflow area' is now
    clearly distinguished from the 'compression buffer'. The latter is a new
    word I introduce.

2.  It renames the BCRSMatrix method parameter _overflowsize to
    compressionBufferSize, because that is what it is: That parameter has
    nothing to do with the 'overflow' data member, or even the concept of
    'overflowing' in general.

3.  It renames the exception 'ImplicitModeOverflowExhausted' to
    'ImplicitModeCompressionBufferExhausted', for the same reason. This is the
    only interface changes. The code keeps the old exception for
    backward-compatibility, but makes it trigger a deprecation warning.

See merge request [core/dune-istl!370]

  [core/dune-istl!370]: gitlab.dune-project.org/core/dune-istl/merge_requests/370

Merge branch 'fix/non-mpi-build' into 'master'

ref:core/dune-istl\> When MPI is not available or explicitly disabled with the
CMake build option -DCMAKE_IDSABLE_FIND_PACKAGE_MPI=TRUE, some tests were
unable to build. I've either fixed or disabled those tests (for those tests
that were testing MPI-only features).

I've also fixed overlappingschawarztest, which did not build when SuperLU was
not found.

The commit concerning MPI should probably be backported to the releases/2.7
branch, as it is affected by the same build failures. The fix for
overlappingschwarztest only appeared after commit
05f80ffa which fixed a bug which previously
disabled the test. Since this commit is not on the releases/2.7 branch, there
is probably no need to backport my fix for overlappingschwarztest.

See merge request [core/dune-istl!372]

  [core/dune-istl!372]: gitlab.dune-project.org/core/dune-istl/merge_requests/372

This test should not be necessary anymore, since commit
05f80ffa fixed the CMAKE_GUARD argument
for this test, so that it is not compiled anymore if either UMFPACK or
SuperLU are missing.

That line had to be removed as it did not compile if either UMFPACK or
SuperLU were missing. For example while I had UMFPACK installed but not
SuperLU, gcc gave me the following error message for the removed line:

…/dune/istl/test/overlappingschwarztest.cc:260:17: error: ‘HAVE_SUPERLU’ was not declared in this scope

Merge branch 'feature/addPythonBindings' into 'master'

See merge request [core/dune-istl!369]

  [core/dune-istl!369]: Nonecore/dune-istl/merge_requests/369

When MPI is not available or explicitly disabled with the CMake build
option -DCMAKE_IDSABLE_FIND_PACKAGE_MPI=TRUE, some tests were unable to
build.

The tests created from solverfactorytest.cc.in and part of
scalarproductstest.cc use Dune::OwnerOverlapCopyCommunication which is
defined behind `#if HAVE_MPI` and is thus not available in a non-MPI
build. I've thus disabled those tests when MPI is unavailable.

The matrixmarkettest did not work without MPI, as it contained some code
using the wrong template parameters when HAVE_MPI was not set. Those
template paramters have been fixed now.

I've confirmed, that after my changes `make build_tests` succeeds to
build all tests and that those tests run without failure.

Python bindings, default is OFF.

Circumstances forced me to finally learn what the BCRSMatrix 'implicit'
build mode really does, and where its limitations come from.  I had
to read the code for that.  As it turns out, the documentation of the
mode is quite misleading.  My main gripe is that the code uses two
different auxiliary data structures, but the documentation calls them
both 'overflow'.  This problem even extends to the variable naming
in the code.  Behold: the parameter 'overflowsize' is NOT the size
of the member 'overflow'.  It doesn't even have anything to do with
that member...

To improve the situation, this patch does three things:
a) It rewrites the documentation.  In particular, the 'overflow area'
   is now clearly distinguished from the 'compression buffer'.
   The latter is a new word I introduce.
b) It renames the BCRSMatrix method parameter _overflowsize to
   compressionBufferSize, because that is what it is:  That parameter
   has nothing to do with the 'overflow' data member, or even the
   concept of 'overflowing' in general.
c) It renames the exception 'ImplicitModeOverflowExhausted' to
   'ImplicitModeCompressionBufferExhausted', for the same reason.
   This is the only interface changes.  The code keeps the old
   exception for backward-compatibility, but makes it trigger a
   deprecation warning.

Merge branch 'feature/cholmod-common' into 'master'

ref:core/dune-istl\> This allows other implementations that are using the
istl-cholmod wrapper to set options and other parameters of the cholmod
solver.

See merge request [core/dune-istl!366]

  [core/dune-istl!366]: gitlab.dune-project.org/core/dune-istl/merge_requests/366

Merge branch 'bugfix/cmake_guard_condition_overlappingschwarztest' into 'master'

ref:core/dune-istl\> This MR fixes the CMAKE_GUARD condition for the
overlappingschwarztest.

See merge request [core/dune-istl!367]

  [core/dune-istl!367]: gitlab.dune-project.org/core/dune-istl/merge_requests/367

This allows other implementations which are using the istl-cholmod wrapper
to set options and other paramters of the cholmod solver

Merge branch 'feature/parallel-solver-factory' into 'master'

ref:core/dune-istl\> This is my proposal for supporting the parallel solvers
in dune-istl with the solver factory.

Summary of the changes:

-   The parallel operators let one get the underlying communication object.
    This is needed to pass it to the parallel preconditioners
-   The solver factory passes the Operator instead of the matrix to the
    preconditioner factory. Thus AMG can be constructed without creating
    another operator from the matrix and we can determine whether we are
    parallel or not by the operator.
-   For the parallel solvers we need to initialize the factory with the
    corresponding parallel operator.

Note that further refactoring might be required to support e.g. the
grid-communcation-based parallelization approaches sometime used in PdeLab.

This is one part of the work proposed in [#82]

See merge request [core/dune-istl!349]

  [#82]: gitlab.dune-project.org/NoneNone/issues/82
  [core/dune-istl!349]: gitlab.dune-project.org/core/dune-istl/merge_requests/349