[CMake] fix installation of refinement.pdf

After the merge of dune-common!115, we have to specify the cmake
target which builds the pdf in `create_doc_install`.

See merge request !23

After the merge of dune-common!115, we have to specify the cmake
target which builds the pdf in `create_doc_install`.

Add .gitlab-ci.yml.



See merge request !22

Fix "warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]"

This was a tricky one.  It was highly non-obvious why the compiler even ran
into this issue.  My best guess is as follows: The compiler was trying to
optimize the loop over the vertices in `testStaticRefinementGeometry()`,
test-refinement.cc:122.  To do this it needed to statically evaluate
`vEnd(refinement)`, where `refinement` is unsigned, but converted to int due to
the signature of `vEnd()`.  The constructed iterator stores it as unsigned
`_level`, and it also stores the current position as unsigned `_index`.  So there
is a conversion from unsigned to int and back to unsigned.

Changing the parameter and return value of `vEnd()` to unsigned turns out not to
be enough: `vEnd` calls `nVertices()`, which also takes and returns an int.
Changing that to unsigned too is still not enough, because `nVertices` evaluates
the expression `Power<dimension>::eval((1<<level)+1)`.  While `level` is now
unsigned, the literal `1`'s are not, and the result of `operator<<()` will have
the type of the (promoted) left operand (the "usual integral conversions" do
not happen for `<<`).  Thus we need to change the literals to `1u`.

To be clear: the warning happens because of conversion from unsigned to int
and then back to unsigned, where the compiler is unable to fully track all
possible values and cannot prove that everything is fine.

This patch fixes this by making the level parameter unsigned, and by making
sure that any literals are suffixed by u.

Adresses #5.

See merge request !19

Fix "warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]"

This was a tricky one.  It was highly non-obvious why the compiler even ran
into this issue.  My best guess is as follows: The compiler was trying to
optimize the loop over the vertices in testStaticRefinementGeometry(),
test-refinement.cc:122.  To do this it needed to statically evaluate
vEnd(refinement), where refinement is unsigned, but converted to int due to
the signature of vEnd().  The constructed iterator stores it as unsigned
_level, and it also stores the current position as unsigned _index.  So there
is a conversion from unsigned to int and back to unsigned.

Changing the parameter and return value of vEnd() to unsigned turns out not to
be enough: vEnd calls nVertices(), which also takes and returns an int.
Changing that to unsigned too is still not enough, because nVertices evaluates
the expression Power<dimension>::eval((1<<level)+1).  While level is now
unsigned, the literal 1's are not, and the result of operator<<() will have
the type of the (promoted) left operand (the "usual integral conversions" do
not happen for <<).  Thus we need to change the literals to 1u.

To be clear: the warning happens because of conversion from unsigned to int
and then back to unsigned, where the compiler is unable to fully track all
possible values and cannot prove that everything is fine.

This patch fixes this by making the level parameter unsigned, and by making
sure that any literals are suffixed by u.

Adresses #5.

[fix] fix strict overflow warnings.

 see issue #5.

See merge request !18

Feature/fix more shadow warnings

GCC 6 revealed even more warnings

See merge request !16

[MultiLinearGeometry] Allow `std::reference_wrapper` of a container as the `CornerStorage`.

This means that the geometry can now easily refer to the actual corner storage
without containing it itself, while still beeing assignable.



See merge request !12

Customization points (like `begin()`) must be found via ADL, which means one
has to do the two-step construct
```
  using std::begin;
  begin(container);
```
Looking at this from a different angle: if a person reading the code sees the
two-step construct, he will likely assume that it is needed to access a
customization point when he is not familiar with the function being invoked.
This leads to confusion if that function is not actually a customization
point, as in this case `cref()`.

[cleanup] fix typos in Doxygen strings



See merge request !14

[test][MultiLinearGeometry] Small demonstration of how the reference_wrapped corner storage can be used.

doc: minor rewording



See merge request !10

There are two extensions:
- It is now sufficient to support `using std::begin; begin(corners);`.
  Previously it was necessary to support `corners.begin();`.  This means that
  C-style arrays should now qualify as corner storage.
- It is now possible to use a `std::reference_wrapper<T>`, where `T` is a
  suitable container, as the corner storage.  This keeps the actual storage out
  of the geometry, which has lifetime and concurrency implications.

CornerStorage.

This means that the geometry can now easily refer to the actual corner storage
without containing it itself, while still beeing assignable.

[GenericGeometry::FieldHelper] Find abs() via argument-dependent lookup, or in std.

This is necessary to work with custom number types.  If they follow the
standard they are not allowed to put their overload of abs() into namespace
std.

Also, this avoids issues with the ordering of includes: if std::abs() is used,
the set of candidates for abs() is fixed when the compiler sees the
GenericGeometry::FieldHelper template.  If the header for the custom number
type is included later, any definition of abs() there won't be taken into
account, even if that header puts that definition into namespace std.  This is
not an issue with argumend-dependent lookup.

See merge request !11

This is necessary to work with custom number types.  If they follow the
standard they are not allowed to put their overload of abs() into namespace
std.

Also, this avoids issues with the ordering of includes: if std::abs() is used,
the set of candidates for abs() is fixed when the compiler sees the
GenericGeometry::FieldHelper template.  If the header for the custom number
type is included later, any definition of abs() there won't be taken into
account, even if that header puts that definition into namespace std.  This is
not an issue with argumend-dependent lookup.

[cmake] bump minimum required version

This is basically redundant, as dune-common requires it, but minimum
versions should be consistent among the core modules.

See merge request !9

[cmake][bugfix] Correct handling of the EXCLUDE_FROM_ALL property:

The signature of `dune_add_test`, that takes the `TARGET` from the user
produced excluded targets if added in a directory that has the directory
property `EXCLUDE_FROM_ALL` set. The correct solution IMO is to not use
that property on test subdirectories anymore (it is a relic from the old
testing magic), because we rely on `dune_add_test` to handle exclusion.

See dune-common#21 for details.

See merge request !8

This is basically redundant, as dune-common requires it, but minimum
versions should be consistent among the core modules.

The signature of `dune_add_test`, that takes the `TARGET` from the user
produced excluded targets if added in a directory that has the directory
property `EXCLUDE_FROM_ALL` set. The correct solution IMO is to not use
that property on test subdirectories anymore (it is a relic from the old
testing magic), because we rely on `dune_add_test` to handle exclusion.

See dune-common#21 for details.

Use <dune/common/array.hh> for fill_array

Undoes an erroneous change from 328dcd16

See merge request !6

Undoes an erroneous change from 328dcd16

Use <array> instead of <dune/common/array>

See also dune-common#13.

See merge request !5

FS#1512 Replace type traits by their standard versions

See dune-common!27 for more information.

See merge request !3

Use constexpr instead of DUNE_CONSTEXPR



See merge request !2

Fix Wshadow warnings

next is geometry, this time even with a range-based for.

See merge request !1