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.

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

Only SuperLU 5 is now supported.

Because the dune-istl matrix interface mandates that this method
be called 'N'.

... which returns the number of scalar entries.  This method
is required by the dune-istl vector interface.

This is the name mandated by the dune-istl interface.

Deprecate the old name 'count'.

* setSolverCategory is not allowed to alter a const value
* Adjust type of setSolverCategory's set
* Properly document deprecation of get/setSolverCategory

!421 changed the signature of the methods `dot()` and `norm()` in
`ScalarProduct`, making them `const`. This breaks compilation of existing user
implementations, so let's document that change.

So, for example, you can write

  BlockVector<double>

instead of

  BlockVector<FieldVector<double,1> >

and it will do what you expect it to do.

There is already the implementation SeqILU, which covers both
the zero-order and the higher-order case together.