Check for the ARPACK++ library (needed for the new Dune::ArPackPlusPlus_Algorithms class template)

initial commit of one class template for performing some iterative
eigenvalue algorithms based on power iteration and of one class
template for performing some eigenvalue algorithms provided by the
ARPACK++ library

The code still uses boost::fusion, though.

These methods should be there in analogy to all other ISTL matrices.
Besides, this patch makes the code use them internally, which makes
for a few nice simplifications.

This removes the dependency on boost::fusion.  Using a bit of variadic template
magic makes the code a tiny bit simpler, too.

Note, though, that this change is not backward-compatible.  If you have previously
used

boost::fusion::at_c<i>(v)

to get the i-th entry of the vector v, you now have to change this to

std::get<i>(v)

Alternatively, you can start using operator[], and write

v[std::integral_constant<int,i>()]

We replace constructs like (if T is a MultiTypeBlockVector)

mpl::size<T>::value

by

T::size()

which I find easier to read.  Besides, using size() hides the fact that
boost::fusion is used for the implementation.

This method mimicks the behavior of normal vector access with square brackets like, e.g., v[5] = 1.
The problem is that the return type is different for each value of the argument in the brackets.
Therefore we implement a trick using std::integral_constant.  To access the first entry of
a MultiTypeBlockVector named v write

  MultiTypeBlockVector<A,B,C,D> v;
  std::integral_constant<int,0> _0;
  v[_0] = ...

The name '_0' used here as a static replacement of the integer number zero is arbitrary.
Any other variable name can be used.  If you don't like the separate variable, you can writee

  MultiTypeBlockVector<A,B,C,D> v;
  v[std::integral_constant<int,0>()] = ...

It has to be enabled via the property SKIP_RETURN_CODE.

The class already contains a method 'count', which returns the same value.
However, all our other vector types use 'size' for the vector size, not
'count'.

Additionally, the method is static and DUNE_CONSTEXPR, which is sometimes
helpful.

Both tests mainly test whether all interface methods compile, and whether
the resulting code does not crash (it doesn't).  A large part of the matrix
test has been copied from the file dune/istl/tutorial/example.cc, which
is really much more of a test than an example.

That test for MultiTypeBlockMatrix seems to trigger a valgrind complaint
inside BCRSMatrix.  I'll need to investigate this.

Both test executables are built even if boost fusion is not found.  In that
case, both simply return '77'.  I am aware that this may not be the official
way to handle the boost dependency, but I didn't want to spend to much time
on the corresponding cmake way to skip the test, given that my plan is
to remove the boost dependency anyway.

modification of member data. This is needed in OPM.

namespace.

This namespace was probably meant to mark implementation details.  However it
led to violations of the ODR (one definition rule), and to warnings about
defined-but-unused functions (see below).

To illustrate the problem consider the function template
Dune::readMatrixMarket:

  template<typename T, typename A, int brows, int bcols>
  void readMatrixMarket(Dune::BCRSMatrix<Dune::FieldMatrix<T,brows,bcols>,A>& matrix,
                        std::istream& istr)
  {
    // ...
    readSparseEntries(matrix, istr, entries, header, NumericWrapper<T>());
  }

The ODR states (§3.2/5):

  There can be more than one definition of a [...] non-static function
  template (14.5.6) [...] in a program provided that each definition appears
  in a different translation unit, and provided the definitions satisfy the
  following requirements.  Given such an entity named D defined in more than
  one translation unit, then

  - each definition of D shall consist of the same sequence of tokens; and

  - in each definition of D, corresponding names, looked up according to 3.4,
    shall refer to an entity defined within the definition of D, or shall
    refer to the same entity, after overload resolution (13.3) and after
    matching of partial template specialization (14.8.3), except that a name
    can refer to a const object with internal or no linkage if the object has
    the same literal type in all definitions of D, and the object is
    initialized with a constant expression (5.19), and the value (but not the
    address) of the object is used, and the object has the same value in all
    definitions of D; and

  [...]

This is violated by e.g. both readSparseEntries, which is defined in the
anonymous namespace.  Since it is not defined within readMatrixMarket, it must
refer to the same entity in all translation units.  However, its name is
effectively Dune::<unique>::readSparseEntries, where <unique> is unique to
each translation unit, and thus it effectively refers to a different entity in
each translation unit, and the program is ill-formed as soon as move than one
translation unit does #include <dune/istl/matrixmarket.hh>.

The warnings by g++-4.9 looked like this:
======================================================================
g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../..  -pthread -I/home/joe/Projekte/pdelab-2.4/dune-common -I/home/joe/Projekte/pdelab-2.4/dune-common -I../../.. -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread -DMPIPP_H -DENABLE_MPI=1   -g -O3 -Wall -MT matrixmarkettest-matrixmarkettest.o -MD -MP -MF .deps/matrixmarkettest-matrixmarkettest.Tpo -c -o matrixmarkettest-matrixmarkettest.o `test -f 'matrixmarkettest.cc' || echo './'`matrixmarkettest.cc
[...]
In file included from matrixmarkettest.cc:11:0:
../../../dune/istl/matrixmarket.hh:501:10: warning: ‘void Dune::{anonymous}::readNextLine(std::istream&, std::ostringstream&, Dune::{anonymous}::LineType&)’ defined but not used [-Wunused-function]
     void readNextLine(std::istream& file, std::ostringstream&, LineType& type)
          ^
In file included from matrixmarkettest.cc:11:0:
../../../dune/istl/matrixmarket.hh:601:19: warning: ‘std::istream& Dune::{anonymous}::operator>>(std::istream&, Dune::{anonymous}::NumericWrapper<Dune::{anonymous}::PatternDummy>&)’ defined but not used [-Wunused-function]
     std::istream& operator>>(std::istream& is, NumericWrapper<PatternDummy>& num)
                   ^
======================================================================

The function is in an anonymous namespace, and it is used nowhere inside
dune-istl.

The standard states (8.3.6/4) that adding default arguments in later
function declarations are only valid for non-template functions.
In matrixmarket.hh, the function template loadMatrixMarket is declared
and a default argument for the last parameter is provided. In
owneroverlapcopy.hh, OwnerOverlapCopyCommunication contains a friend
declaration of loadMatrixMarket without the default parameter. If now
owneroverlapcopy.hh is included before matrixmarket.hh, the friend
declaration is the first declaration and the default parameter in
matrixmarket.hh is invalid.
By including matrixmarket.hh in owneroverlapcopy.hh, we make sure that
the declaration which provides the default argument is always the first
one.

This test actually does test the parallel functionality
that is now contained in dune-common for quite some time.
While it is using BlockVector this is not needed by the test.
It works with any container supporting operator[].

Therefore this commit gets rid of BlockVector and uses std::vector
instead. This will allow us to move the test to dune-core subsequently.

Previously, we assumed that if a_{ij} is stored in the sparse matrix
then a_{ji} must be stored also and used mat[i][j] to access. If the entry
was not stored then an exception somewhere in basearray.hh was thrown.
Unfortunately knowing the cause for this exception is insider knowledge,
seldomly leaked ;). In addition there is now reason to throw an expection here.

With this commit we the find method on the row to search for the entry a_{ji}.
If it is not present we simply treat it as being zero.

Fixes FS#FS#1649.

extended the amgtest to also use field_type = complex by switching the
definition of XREAL