This method adds a value to an entry. In contrast to
`matrixBackend(row,col) += value`, the new
`matrixBackend.addToEntry(row,col,value)` can ignore
nonexisting entries to support e.g. `DiagonalMatrix`.

Avoid the deprecated file istlbackend.hh

See merge request !152

[cleanup] Don't zero-initialize matrix in local assemblers

See merge request !151

Zero-initilization already happens in the global assembler. Hence you
don't need to and in fact should not do this in the local one, too.
This has the advantage, that you can chain local assembler. E.g. you
can get a local assembler for the H^1 norm using

```cpp
auto massAssembler = Dune::Fufem::MassAssembler();
auto laplaceAssembler = Dune::Fufem::LaplaceAssembler();
auto h1Assembler = [=](auto&&... args) {
  massAssembler(args...);
  laplaceAssembler(args...);
};
```

or by implementing an abstract utility

```cpp
auto sumLocalAssembler = [](auto... localAssemblers) {
  return [=] (auto&&... args) {
    std::initializer_list<int> { (localAssemblers(args...), 0)...};
  };
};
auto h1Assembler = sumLocalAssembler(Dune::Fufem::MassAssembler(), Dune::Fufem::LaplaceAssembler());
```

[cleanup]Simplify ISTLMatrixBackend entry access by multi-indices

See merge request !149

Capturing structured bindings by reference is not allowed
before C++20. Here we can instead capture by value as a work around,
because the shifted indices are thin wrappers.

This removed some trivial tests and instead introduces
some more systematic tests with more complicated matrix
types and bases. Since the `MatrixBuilder` has not been
specialized for some of the tested matrix types, the
corresponding matrices must be created manually.

This cleans up the entry access by a pair of row- and column-multi-indices
as follows:

* Factor out a generic utility function `visitMatrixEntry()` for
  accessing the `(i,j)`-th entry of a matrix with dynamic indices.
  By combining `hybridIndexAccess()` and `hybridRowIndexAccess()` this
  also works with multi-type matrices.
* Factor out a generic utility function `visitMatrixEntryRecursive()` for
  recursively accessing matrix entries with dynamic row- and column-multi-indices.
  The action to apply to the resolved matrix entry is customizable.
* Use `visitMatrixEntryRecursive()` to return matrix entries.

This is a significant simplification of the old `MultiIndexResolver`-code
and far more readable. It is also more generic, and forms the foundation
of possible extensions to other methods that need multi-index-access,
like, e.g., `matrixEntryExists(i,j)` or `addToMatrixEntry(i,j)`.

Split header assemblers/istlbackend.hh

See merge request !148

The header contained several independent classes. They are now
split into separate headers in the new directory `backends/`.
The old header is deprecated but includes the new one for compatibility.

Stop using Dune::VirtualFunction interface

See merge request !146

* Remove `AlienElementLocalBasisFunction` and corresponding header.
  This is overly complicated and can be implemented simpler
  using the new `CachedFunction`.
* Replace use of `AlienElementLocalBasisFunction` in dofconstraints.hh
  in favor of a direct implementation.

Switch from old `BasisGridFunction` to Dune::Functions::DiscreteGlobalBasisFunction`
in the test, to avoid deprecation warning.

In all placed where this class is used, the downstream code
uses `operator()`.

* Use CachedFunction instead.
* Remove now unused classes `LocalBasisDerivativeFunction`
  and `LocalBasisJacobianFunction` and corresponding headers.
  They are not used anywhere.

This is a simple wrapper for caching function evaluations. Together
with very simple application specific lambda functions this provides
the same functionality as `CachedComponentWrapper` with a far simpler
implementation without CRTP, traits-classes, ... .

* Let the function implement the dune-functions interface
* Require dune-functions in `exportGreyMap()` member function
* Adjust `pgmtest.cc`

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

* Let the function implement the dune-functions interface
* Require dune-functions in `exportPixelMap()` member function
* Adjust `ppmtest.cc`

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

* Switch to dune-functions interface for grid functions
* Adjust `newpfeassemblertest.cc`

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

This allows to e.g. use `Dune::Functions::DiscreteGlobalBasisFunction`
with a wrapped basis without storing a separate copy of it.

* Switch to dune-functions interface for grid functions
* Adjust `secondorderassemblertest.cc`

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

* Switch to dune-functions interface for grid functions
* One now has to pass a dune-functions basis to
  `FunctionIntegrator::integrateDiscreteFunction()`
* The function range type must be passed manually as
  template parameter to `FunctionIntegrator::integrateDiscreteFunction()`.
* Adjust test

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

Adjust test to recent changes in `L2FunctionalAssembler`, `H1FunctionalAssembler`,
`SubgridL2FunctionalAssembler`, and `SubgridH1FunctionalAssembler`:

* Test with functions implementing the new interface.
* Pass suitable `QuadratureRuleKey`s to constructors.

* Switch to dune-functions interface for grid functions
* Modernize constructor: You now have to pass a `QuadratureRuleKey`
  describing how to integrade the passed function instead of
  a raw quadrature rule order for the whole integrant.
* Reduce magic:
  * This no longer works like a simple `H1FunctionalAssembler`
    if you pass Subgrid `GridFunction`s. In this use case
    use a plain `H1FunctionalAssembler` instead.

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

* Switch to dune-functions interface for grid functions
* Reduce magic:
  * This no longer works like a simple `L2FunctionalAssembler`
    if you pass Subgrid `GridFunction`s. In this use case
    use a plain `L2FunctionalAssembler` instead.
  * The `QuadratureRuleKey` is no longer determined from the passed
    function automatically. Instead the manually passed `QuadratureRuleKey`
    is now always used.

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

Remove the deprecated constructor taking a raw quadrature order,
the now unused member storing this order, and all code paths evaluating it.

* Switch to dune-functions interface for grid functions
* Modernize constructor: You now have to pass a `QuadratureRuleKey`
  describing how to integrade the passed function instead of
  a raw quadrature rule order for the whole integrant.
* Adjust test
* Disable test for dune-functions older than 2.9, because
  `derivative(DiscreteGlobalBasisFunction)` is used in the
  test but not implemented in before dune-functions-2.9.

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`,
but have to use either the `std::function` or the `Dune::Functions::GridViewFunction` interface.

This moves the `Local(Derivative)Evaluator` implementations from
`basisgridfunction.hh` to `vintagebasisgridfunction.hh`. Hence
the former now includes the latter. This was the other way around before.

By this change one can include `vintagebasisgridfunction.hh` without
seeing deprecation warnings because `dune/common/function.hh` is implicitly
included. Furthermore it allows to remove `basisgridfunction.hh` before
`vintagebasisgridfunction.hh`.

* Switch to dune-functions interface for grid functions
* Adjust test
* Also test with scalar- and matrix-valued dune-functions grid functions as coefficients
* Disable test with `Dune::Functions::ComposedGridFunction` for dune-functions-2.8

After this patch you can no longer pass a `Dune::VirtualFunction` or `VirtualGridFunction`
as diffusivity coefficient, but have to use either the `std::function` or the
`Dune::Functions::GridViewFunction` interface.

All utilities in this header are for transitional purposes to
migrate dune-fufem from the `Dune::VirtualFunction`-based to a
`std::function`-based interface, while keeping some compatibility.

Unfortunately the dune-functions utilities (e.g. `makeGridViewFunction()`)
cannot directly be used, because the old dune-fufem assemblers do not
know a `GridView`, but only a `Grid`, while the dune-functions grid-function
concept always required an `EntitySet` that typically represents a `GridView`.
The work-around provided by this header works as follows:

* Provide a utility `Dune::Fufem::Impl::localFunctionForGrid<Grid>(f)`
  that creates a local function suitable for a given `Grid` type - either by
  forwarding to `localFunction(f)` or by providing a wrapper.
* To avoid implementing the wrapper again, `Dune::Functions::AnalyticGridViewFunction`
  is reused with a dummy `Dune::Fufem::Impl::AllEntityGridView` that contains all
  entities (but does not allow iteration or to obtain an index set).
* Since the `GridView` type may differ, depending on which code path
  is used to create the grid function, we cannot directly store the
  global grid function in a `Dune::Functions::GridFunction` type-erasure
  wrapper. Instead we have to store the local function in a
  `Dune::Functions::LocalFunction` that only depends on the entity type.
  Since creating precise type of the latter from the `Grid` and `Range`
  is a little cumbersome, this is simplified by the alias
  `Dune::Fufem::Impl::LocalFunctionInterfaceForGrid<Grid,Range>`.

Remove deprecated headers

See merge request !147