[examples][test] Avoid deprecation

See merge request !532

Always provide an index merging strategy, to avoid
the deprecation warning for the changing default.

Inform users of pending change of default index merging strategies

See merge request !530

Using `functions.Power` in Python to construct function space
basis trees without an explicit `layout` argument will now
issue a warning. This warning informs that the default value
will change from `lexicographic` to `interleaved` after the
2.11 release. This change will bring the defaults in line with
what the C++ interface does.

Using the methods `power` or `composite` to construct function space
basis trees without an explicit index merging strategy argument
will now issue a warning. This warning informs that the default
index merging strategy will change after the 2.11 release.
More specifically, it will change from `BlockedLexicographic`
to `FlatLexicographic` for the `composite` method, and from
`BlockedInterleaved` to `FlatInterleaved` for the `power` method.
The consequence is that default indexing is always flat,
which is the most common form of indexing.

To ensure a smooth transition we suggest to not rely on default
index merging strategies until 2.11 has been released.

Improve setup of generic node information (and avoid applyToTree)

See merge request !528

The node header contained three visitors for
* initially setting the tree indices,
* binding the tree,
* and clearing the node size information.

The latter is removed because it was undocumented
and unused for years. The one for setting the tree
indices is replaced by a call to `forEachNode()`.
Binding of the tree is now handled recursively
by adding a `bind(element)` method to inner nodes, too,
which calls bind for its children and sets their offsets.
This way one can hook in the mechanism as follows:

It is possible to derive from one of the inner node
classes and overwrite the `bind(element)` method.
In cases where it is known in advance that a child
has size zero (e.g. for a multi-domain grid view)
this allows to skip the costly bind operation for
the children.

[cleanup] Remove stuff deprecated in 2.10

See merge request !527

[python][cleanup] Don't specialize DimRange for nodes

See merge request !523

Use `Dune::Functions::BasisFactory` instead.

Don't use typetree nodetags in basis concept

See merge request !522

The `DimRange` template class from dune-common is used
to spezialize for range types in order to specify the
corresponding range dimension. Specializing `DimRange`
for a node seems to be rather odd. Furthermore this is
only used locally in `registerBasisType()`. Hence we
effectively abuse `DimRange` to sum up the leaf node
range dimensions recursively.

This patch replaces the construction by a simple
recursive `constexpr` function and by the way replaces
the clumsy check for node tags by `is(Leaf|Power|Composite)`
and introduces a static assertion for the non-supported
dynamic power case.

Add some missing constructors to CompositeBasisNode to allow for CTAD

See merge request !485

Fix the filename in CMakeLists of finefunctiononcoarsegridview

See merge request !526

Here we don't need the tags, because `Node::is(leaf|power|Composite)`
and the existence of `Node::degree()` provide all the needed
information.

[cleanup] Remove unused typetree includes

See merge request !521

[cleanup] Stop passing shared_ptr to nodes explicitly in TaylorHoodBasis

See merge request !520

Add support for dynamic order to LagrangeDGPreBasis

See merge request !513

This add support for providing the polynomial order
dynamically to `LagrangeDGPreBasis` analogously to
´LagrangePreBasis`. Additionally this implements some
minor improvements/changes:

* Allow to select range type using a template parameter.
* Base implementation on `LeafPreBasisMapperMixIn` to drop
  a bit of boilerplate code.
* Improve documentation.
* Deprecate the `dofsPer(...)` static member variable that only make
  sense for compile time order.

Add utilities CoarseGridViewFunction, FineGridViewFunction and GeometryInAncestor

See merge request !511

[bugfix][test] Update basis after grid was modified

See merge request !518

The test creates the basis, refines the grid and then
uses the basis. This is undefined behaviour and just
happened to work accidentally because the `LangrangeBasis`
implementation computes the dimension on the fly instead
of relying on a mapper that precomputes its size.

The correct behavious is to either create or update the
basis after refinement.

Mention `CoarseFunctionOnFineGridView`, FineFunctionOnCoarseGridView`
and `GeometryInAncestor` in change log.

Rename:
* `FineGridViewFunction` -> `FineFunctionOnCoarseGridView`
* `CoarseGridViewFunction` -> `CoarseFunctionOnFineGridView`

The test functions after mapping between gridviews several
type for different grid types in 2d and 3d.

This implements a helper functions for the l1-distance
to a `ReferenceElement` and uses it to traverse to
the child closest to the evaluation point.

Assume that for a given `gridView` the function
`f` is a `GridFunction` defined on some entity
set of the same grid which is finer than the
`gridView` in the sense that each element in the
`gridView` is covered by (not necessarily direct)
descendent elements `e` satisfying `f.entitySet().contains(e)`.
Then this utility allows to represent `f` as
a `GridViewFunction` on the `gridView` using

```cpp
auto fgvf = FineGridViewFunction(f, gridView);
```

When bound to an element `e` from the `gridView`
and evaluated locally at some point `x`,
this internally searches for a descendet element
in `f.entitySet()` that contains `x` and
translates local coordinates.

Assume that for a given `gridView` the function
`f` is a `GridFunction` defined on some entity
set of the same grid which is coarser than the
`gridView` in the sense that each element in the
`gridView` has an ancestor `e` satisfying
`f.entitySet().contains(e)`.
Then this utility allows to represent `f` as
a `GridViewFunction` on the `gridView` using

```cpp
auto cgvf = CoarseGridViewFunction(f, gridView);
```

When bound to an element from the `gridView`,
this internally searches for an ancestor where
`f` is defined and translates local coordinates.

This class represents the geometric embedding
of an element into an acestor by chaining
`geometryInFather()` objects. This information
is computed from a given fine element and a
predicate. The tranversal towards the ancestors
stops at the first element where the predicate
is not satisfied. This element is considered
as coarse element.

While an alternative interface where the coarse
element is the last one satisfyin the predicate
seems to be simpler at first, the one proposed
here is nicer for several reasons:

* If the element range only consists of elements
  satisfying the predicate, we may end up with
  an empty range if the starting element does not
  satisfy it. With the proposed aproach we end up
  with the identity on the fine element.
* There are several applications where the proposed
  interface is very natural, e.g. traversing towards
  the first element that persists after refinement.
* A criterion that first needs to obtain an ancestor
  before it can be decided if it should be included
  is more expensive.

Add include directories to library target

See merge request !512