[multidomain] Various small cleanups, remove unnecessary/potentially buggy lines of code, add useMoles.

Note: this leads to a change how to set boundary conditions for the momentum balance. Inflow now becomes Dirichlet and Outflow becomes Neumann. This is consistent with the new notation.

[problem] Move isCornerPoint() to more upstream position, because it may be used in other circumstances, too.

[multidomain,BeaversJoseph] Use BJCoeff() from the Darcy spatial parameters which is more meaningful.

This includes proper warnings and removal of the SpatialParams objects.

- removed TODOs in deprecated functions
- add use of shared pointer (in multidomainmodel.hh and multidomainconvergencewriter.hh)
- adapt to nonlinear, common classes
- adjust indentation (which changed due to removal of tabs)
- adapt doxygen docu

This time:
  - deprecated old coupling12() and coupling21() and replaced them by one coupling()
  - try to group boundary condition types
  - unified naming and steps how fluxes are calculated (nothing new was added)
  - further replacing _s, _n by 1, 2

boundaryLayerModel: spurious changes in (~4% for 1e-11 and 1% for 1e-9 in velocity)

This has the following advantages:
 - reuse the BL model in the non-isothermal case
 - possible move of the functions to more problem specific place (due to the use of runtime parameters)
 - better comparison of what is actually done in the code

Update reference solution, because for the BL Model the gas viscosity from Darcy was used.

[multidomain,Beavers-Joseph] Move evalBeaversJoseph to LOP which prevents a reimplementation in the non-isothermal coupling local residual.

Move beaversJospehCoeff to SpatialParamters, where it belongs.
Changes in reference solution was triggered, comments see below.

2cstokes2p2c:
Checked storage.out (e.g. the evaporation rate):
  - changes were lass than 1 per mile.
Checked vertical velocity profiles in the middle of the domain:
  - v_0: no visible difference
  - v_1: main deviation (5%) in middle, where the profile is oscillating anyway and NOT at the interface
Checked horizontal velocity profiles:
  - v_0: small differences towards the outflow boundary
  - v_1: difference during the profile development

2cnizeroeq2p2cni (freeflow):
Checked vertical velocity profiles in the middle of the domain:
  - v_0: no visible difference
  - v_1: no visible difference
Checked horizontal velocity profiles:
  - v_0: no visible difference
  - v_1: small differences towards the outflow boundary

2cnizeroeq2p2cni (porousmedium):
Checked vertical velocity profiles in the middle of the domain:
  - v_0: no visible difference
  - v_1: very small deviation towards the interface (3%)

Integrated evalCouplingVertexFunction into evalBoundary.
Adjusted the difference in the coupling boundary handling between isothermal and non-isothermal case.
Removed very potentially never used portion of code.

[2cstokes2p2c,2cnistokes2p2cni] Remove not maintained and potentially very model specific output of fluxes.

[localresiduals] Remove duplicate and wrongly documented evaluation functions, which have only been used for output purposes.

Save in runtime (old: 600s, new: 120s)

[boundarytypes,non-isothermal] Revert boundarytypes to almost original state (see below), update the non-isothermal models and reference solutions.

Problems occured if the boundary types are herited or more precise the problem was to reset out of the parent class the boundary types from the childs classes.

[boundaryconditions,stokes2csubproblem] Apply changes for the boundary condition names to the Stokes2c side removed unused boundary condition flags.

Small cleanup, removal of unused code and Mortar.

Removed code for the treatment of corners at the coupling/outer boundary edge. The code was very different between isothermal and non-isothermal case. The per-se more used and more trustworthy non-isothermal case had some contradicting if clauses.

However in most cases used at the LH2 this part of code remains unused.

Feature/colebrookwhiteboundarylayer



See merge request !30

[linear] remove self-written parallel linear solvers

In dumux/linear/boxlinearsolver.hh, there are several linear solver
backends which use "self-written" infrastructure for parallel runs
from several files in dumux/linear.

Deprecate those solvers and the infrastructure files due to the
following reasons:

- The parallelism is restricted to box.

- The iteration counts deteriorate with growing process numbers.

- The code is hard to maintain or to generalize.

- We have the general / rather robust / mostly upstream-maintained AMGBackend.

Use the corresponding sequential solvers from seqsolverbackend.hh by
default and in the serial tests.

This implements FS#293.

See merge request !28

In dumux/linear/boxlinearsolver.hh, there are several linear solver
backends which use "self-written" infrastructure for parallel runs
from several files in dumux/linear.

Deprecate those solvers and the infrastructure files due to the
following reasons:

- The parallelism is restricted to box.

- The iteration counts deteriorate with growing process numbers.

- The code is hard to maintain or to generalize.

- We have the general / rather robust / mostly upstream-maintained AMGBackend.

Use the corresponding sequential solvers from seqsolverbackend.hh by
default and in the serial tests.

This implements FS#293.

Feature/various small fixes



See merge request !29