Feature/parameterizedobjectfactory

the idea is to have a generic factory which can be extended by the user at run time and maps a key (usually an `std::string`) to a constructor-call (usually taking a `Dune::ParameterTree`).

We want something like a plugin-system, to instantiate implementations of an abstract interface. Usually a factory can only create a hard-coded list of objects. The proposed ParameterizedObjectFactory different modules (or the user) can register implementations of the interface, without modifying the factory code.

Example:
```C++
using V = Dune::BlockVector<Dune::FieldVector<double,2>>;
using M = Dune::BCRSMatrix<Dune::FieldMatrix<double,2,2>>;

using PreconditionerFactory = 
  Dune::ParameterizedObjectFactory<Dune::Preconditioner<V,V>(const M&, const Dune::ParameterTree&)>;

PreconditionerFactory::define<Dune::SeqGS<M,V,V>>("Gauss-Seidel");
```


See merge request !3

[fmatrixtest] Drop dummy.f.

I have no idea why `fmatrixtest` compiled and linked `dummy.f`, and it made
compilation fail in the absence of gfortran.

[DONE] Check that linking against a static liblapack still works. (`fmatrixtest` simply does not seem to need lapack)

Planned merge: 2016-11-26


See merge request !178

- add more use cases
- add a factory, which is managed by a singleton
- add some predefined types to factory in a separate object to make
  sure that we can properly access the same factory from different
  compilation units
- access to the factory singleton is managed by a global function

Add macro DUNE_ASSERT_AND_RETURN

This is an alternative to !128.

In C++11 and with not fully C++14 compliant compilers `constexpr` functions
can only have a return statement. This prevents the use of `assert()` inside
of `constexpr` functions. This macro can be used as a workaround like this:

```c++
  constexpr auto foo(int a, int b, x)
  {
    return DUNE_ASSERT_AND_RETURN(a<b, x);
  }
```

For `NDEBUG` there is no penalty. Otherwise there are two options:
* In a non-`constexpr` context an `assert()` will fail if the condition
  is not matched. The error message will be slightly different from a
  classic assertion.
* In a `constexpr` context the `assert()` branch will be ignored if the
  is condition is matched. Otherwise this will lead to a compile error
  (like `static_assert`) because the branch using `assert()` is not `constexpr`.

See merge request !142

Do not set and empty CMAKE_MODULE_PATH when calling cmake.

It seems like this causes problems on some platforms. If the path is empty
we can leave it unset anyway.

See merge request !175

Use CMAKE_GUARD for tests that require MPI

This results in a consistent message explaining why the test was
skipped.

See merge request !185

This results in a consistent message explaining why the test was
skipped.

Fix `max_value` and `min_value`

This merge request adds a test for `rangeutilities.hh` and corrects `max_value` and `min_value`.

See merge request !183

This avoids using the uninitialized variable `m` in the loop. Note that
calling `max_value` or `min_value` on an empty list will now result in
undefined behavior as the end iterator is then dereferenced.

The test is expected to fail due to use of uninitialized variables in
`max_value` and `min_value`:

```
CHECK   FAILED: minimum of positiveValues is 1, but got 0
CHECK   FAILED: maximum of negativeValues is -1, but got 0
TEST    FAILED: 2/18 checks failed in this test.
```

Closes #58

`v` is a const reference, so we can only return a const reference.

Add correct offset for end of chunk

Using `&current->chunk_ + x` will add `x * sizeof(current->chunk_)` to
the pointer, but we only want to add `x`.

Adding a much larger number still "works" on 64bit systems (although it
does not perform the intended check). However on 32bit platforms this
wraps (at least in the way used by sllisttest.cc) and the "end" of the
chunk is suddenly before the beginning.

Closes #57

See merge request !181

Using `&current->chunk_ + x` will add `x * sizeof(current->chunk_)` to
the pointer, but we only want to add `x`.

Adding a much larger number still "works" on 64bit systems (although it
does not perform the intended check). However on 32bit platforms this
wraps (at least in the way used by sllisttest.cc) and the "end" of the
chunk is suddenly before the beginning.

Closes #57

[bugfix] Fix possible memory corruption in ForLoop

The reason for perfect forwarding is to also forward r-values as
r-value references such that the called function can do a move
on such values.
As a consequence you should never call `std::forward` on the same
object twice because the second function may get a moved from
object since the first one has already stolen the data. E.g.
for the following operation
```cpp
  template<int i>
  struct Operation
  {
    static void apply(std::vector<int> v)
    {}
  };
```
a call to
```cpp
  Dune::ForLoop<Operation, 0, 1>::apply(std::vector<int>{1,2,3});
```
will pass a moved from vector in an undefined state on the second call.

BTW: The same error existed in the old implementation of `ForLoop`

See merge request !177

I have no idea why this was done, and it made compilation fail in the absence
of gfortran.

The reason for perfect forwarding is to also forward r-values as
r-value references such that the called function can do a move
on such values.

As a consequence you should never call std::forward on the same
object twice because the second function may get a moved from
object since the first one has already stolen the data. E.g.
for the following operation

  template<int i>
  struct Operation
  {
    static void apply(std::vector<int> v)
    {}
  };

a call to

  Dune::ForLoop<Operation, 0, 1>::apply(std::vector<int>{1,2,3});

will pass a moved from vector in an undefined state on the second call.

BTW: The same error existed in the old implementation of ForLoop

[cleanup] fix warning: extra ‘;’ [-Wpedantic]

This removes the extra ‘;’ warnings when compiling with -Wpedantic.

See merge request !176

It seems like this causes problems on some platforms. If the path is empty
we can leave it unset anyway.

Update man page of dunecontrol

Closes #52

See merge request !159

Vectorize FieldMatrix

Vectorize enough of `FieldMatrix` to make dune-geometry!13 work.

- [DONE] Fix buildsystem.
- [DONE] Ensure no performance regression.
- [DONE] Investigate anti-speedup in vectorized 1×1 `solve()`. (The effect disappeared in later benchmarks)
- [DONE] Merge with current master.
- [DONE] Wait for comments until at least 2016-11-17.

See merge request !121

[test] Check Std::apply() by implementing a tuple transformation

This checks with a real application example: An implementation
of a tuple transformation.

Maybe we also want to implement our real tuple tranformation
that way, because its easier to read and much shorter.

See merge request !171

Feature/add integersequenceentry

The traits class `IntegerSequenceEntry` computes the i-th entry
of an `std::integer_sequence`. The `integerSequenceEntry` helper
function does the same with function syntax.
    
 This allows to avoid the hight template instantiation depth
 of `std::make_tuple` when using the "natural" implementation

```cpp    
std::get<index>(std::make_tuple(t...));
```
    
The latter adds 15 instantiation levels per argument whereas
the still recursive implementation in this MR adds only one.

See merge request !170

MPIHelper should only finalize MPI if it called init

MPIHelper only calls MPI if it was not already called before MPIHelper is constructed. Finalize is however always called on destruction leading to
problems with other packages calling init/finalize before/after MPIHelper
is setup. Added a bool storing the information if MPIInit was called by the
MPIHelper so that finalize is only called in that case.

See merge request !58

This checks with a real application example: An implementation
of a tuple transformation.

Maybe we also want to implement our real tuple tranformation
that way, because its easier to read and much shorter.

Now the template instantiation depth for an integer_sequence
of length n is ~n instead of ~15n (for gcc 6).

The traits class IntegerSequenceEntry computes the i-th entry
of an std::integer_sequence. The integerSequenceEntry helper
function does the same with function syntax.

This allows to avoid the hight template instantiation depth
of std::make_tuple when using the "natural" implementation

  std::get<index>(std::make_tuple(t...))

The letter adds 15 instantiation levels per argument whereas
the still recursive implementation in this commit adds only one.

Deprecate ForLoop, ForEachValue and ForEachValuePair

Deprecate `ForLoop`, `ForEachValue` and `ForEachValuePair` since they are only a useless wrapper around the generic `Hybrid::forEach`.

See merge request !169