[cmake] extract bottom block from config.h.cmake

For dune-grid a bottom section is needed to place the Grid Type magic at the bottom of the config.h
file in derived modules.

In this patch a /* begin bottom */ ... /* end bottom */ block from each module's config.h.cmake file and placed
at the end of the collected config.h file.

This resolves the problems from FS#1713 if the same branch is applied in dune-grid.

See merge request !19

[CMake] Rewrite C++ standard detection

This is a complete rewrite of the existing C++ standard version test
that tries the various `-std=c++xy` flags and tries to figure out which
version of the standard to enable.

The existing version has a few problems:

- it is not really extensible to newer standards, those will just lead
to a deeper and deeper nesting of `if` statements.

- More importantly, there is no way to say: I want C++11, but not C++14
  (or, in the future, I want C++14, but not C++17). Being able to do so
  is important for testing and compatibility reason.

- There is no easy way for downstream modules to require a newer version
  of the standard than the core modules.

## Test logic

The new version of the test separates the logic from the data (versions,
flag names, compiler test sources) and just iterates over lists of that
data, in descending order to make sure the newest available standard
gets picked. The numerical value of that standard is stored in the
variable `CXX_MAX_SUPPORTED_STANDARD` and the test stops. If the test
fails to find a working combination, it issues a warning to the user and
only records support for C++03.

The test can be influenced by two CMake variables:

- `DISABLE_CXX_VERSION_CHECK` already existed in the old version of the
  test. It completely disables all testing and requires the user to
  manually set `CXX_MAX_SUPPORTED_STANDARD` to the correct value.
  Moreover, any required compiler command line switches have to be
  manually added to `CMAKE_CXX_FLAGS`.

- `CXX_MAX_STANDARD` defines the maximum version of the standard that
  the build system will try to enable. With this new switch, it becomes
  possible to limit the compiler to an older version of the standard
  than what it could theoretically support. For now, this defaults to
  C++14.

## Requirements check with a new CMake function

In order to allow module authors to easily state their minimum version
requirements, there is a new CMake function
`dune_require_cxx_standard()` that any Dune module can call to require
support for at least a given C++ standard:

```
dune_require_cxx_standard(MODULE "dune-functions" VERSION 14)
```

If the compiler doesn't meet the requirements, the function will report
the required and the actually available standard versions and abort with
a fatal error.

Moreover, it knows about CXX_MAX_STANDARD and will tell the user if the
value of that variable is below the requirements. This avoids desperate
users that have a shiny beta of GCC 6 with C++17 support wondering why
their own module using shiny C++17 concepts stubbornly fails to build...

This fixes #16, and a backport to 2.4 will also be a fix for #15.

See merge request !46

Probably introduced accidentally in commit daa2e9f4.

FindSuiteSparse.cmake: Correct `HAVE_SUITESPARSE_${_component}`



See merge request !47

The value of the variable `SuiteSparse_${_component}_FOUND` should be
assigned, not the name of the variable.

The construct `set(variable (x and y))` will assign the list `"x;and;y"`
to `variable` instead of evaluating the expression.

Thanks to Elias Pipping for pointing this out.

Oops.

This patch adds a new function dune_require_cxx_standard() that any Dune
module can call to require support for at least a given C++
standard. If the compiler doesn't meet the requirements, the function
will report the required and the actually available standard versions
and abort with a fatal error.

Moreover, it knows about CXX_MAX_STANDARD and will tell the user if the
value of that variable is below the requirements. This avoids desperate
users that have a shiny beta of GCC 6 with C++17 support wondering why
their own module using shiny C++17 concepts stubbornly fails to
build... ;-)

This patch is a complete rewrite of the existing C++ standard version
test that tries the various -std=c++xy flags and tries to figure out
which version of the standard to enable.

While my cleaned-up version of the old implementation generally works,
it has a few problems:

- it is not really extensible to newer standards (that will lead to the
  same kind of mess as before).

- More importantly, there is no way to say: I want C++11, but not
  C++14 (or, in the future, I want C++14, but not C++17). Being able to
  do so is important for testing and compatibility reason.

So this patch mostly starts from scratch: There is a list of supported
C++ standards (currently 17,14,11) and corresponding lists of compiler
tests and compiler flags to switch the compiler to the respective
standards (there might be different values for the switch, e.g. some
compilers accept -std=c++1y, but not -std=c++14, and recent versions of
GCC reject -std=c++1x).

The code then just iterates through these versions and flags until it
finds one that works. If that flag / version combo also passes the
compile test, the maximum supported standard version is recorded in the
variable CXX_MAX_SUPPORTED_STANDARD and the test stops. If the test
fails to find a working combination, it issues a warning to the user and
only records support for C++03.

The test can be influenced by two CMake variables:

- DISABLE_CXX_VERSION_CHECK already existed in the old version of the
  test. It completely disables all testing and requires the user to
  manually set CXX_MAX_SUPPORTED_STANDARD to the correct
  value. Moreover, any required compiler command line switches have to
  be manually added to CMAKE_CXX_FLAGS.

- CXX_MAX_STANDARD defines the maximum version of the standard that the
  build system will try to enable. With this new switch, it becomes
  possible to limit the compiler to an older version of the standard
  than what it could theoretically support. For now, this defaults to
  C++14.

This patch cleans up the logic of the C++ version flag detection code,
which had accumulated quite a bit of cruft over time.

Moreover, it also adds a new test for basic C++11 compliance which is
always run, even if DISABLE_CXX_VERSION_CHECK has been set. I think the
original code was supposed to also error out in this case, but I didn't
really do so.

With this patch, DISABLE_CXX_VERSION_CHECK really only disables testing
for the various -std=c++xy flags, but the build system will now always
make sure that your compiler runs (at least) in C++11 mode.

CMAKE_REQUIRED_FLAGS is explicitly designed for temporary flags used in
CMake's various check_<something> macros, so don't store any test
outcome in there.

The C++ version flag check used to set the -std=... flag for both the
basic CMAKE_CXX_FLAGS and the build-specific variants of it. That is
unnecessary because CMAKE concatenates the base variable and the
build-specific variant (if a build type has been set by the
user). Having both is actually rather unhelpful, as any downstream
changes will also have to be done to the complete set of variables.

[cleanup] replace last usage of Dune::Conversion

The deprecated type trait Dune::Conversion was still used in dune/common/densematrix.hh and will be replaced by std::is_convertible in this merge request.

This is a follow-up to merge request !37.

See merge request !45

This is a follow-up to merge request !37.

See also flyspray/FS#1669

A FieldMatrix can still have a DiagonalMatrix assigned to it through the
new DenseMatrixAssigner specialisation. The restriction from general
DenseMatrix implementations to the FieldMatrix class is removed in the
process.

The functionality is retained in the form of a DenseMatrixAssigner
specialisation, except for C-style matrices.

See also flyspray/FS#1669 and #11

The point of the matter is that posix_memalign() is not allowed in this
context according to the relevant standards, so we use mmap() instad.

`mprotect` can only be used for `mmap`'ed memory

Makes testdebugallocator pass on OS X, too.

See merge request !43

mprotect violations are required to lead to a SIGSEGV on Linux.
OS X is more permissive, allowing for both SIGSEGV and SIGBUS.

And practice, the tests generate a SIGBUS for me, causing the tests to
fail. Confusingly, ctest describes the problem as

  Exception: SegFault

which I assume they use as a catch-all term.

The combination of `posix_memalign` and `mprotect` does not work as
expected on OS X, see also !43.

[Cleanup] Fix GCC warning by properly initializing member



See merge request !41

feature/ use std::is_convertible istead of Dune::Conversion



See merge request !37

Feature/debugstream destructor exception



See merge request !35