* Group methods according to new and old assembler interface
* Remove documented code

The boundary intersection assemblers in `Dune::Fufem::Forms`
no longer hide the intersection assembler behind the
`LocalElement(Matrix|Vector)Assembler` interface but directly
implement the `LocalBoundaryIntersection(Matrix|Vector)Assembler`
interface.

It is now possible to mix element and boundary intersection
assemblers within a `LocalSumAssembler`. Matrix- and vector-assemblers
are both supported.

[cleanup] Remove code based on old basis and function interfaces

See merge request !263

[examples][bugfix] Only use AdolC if it is available

See merge request !265

[examples] Do not always build examples

See merge request !266

With the number of examples increasing, the build time
can be annoying. This follows the approach taken in dune-functions
and excludes the examples from plain `make`. Instead it adds
a dedicated target `make build_examples` which is included in
`make build_tests`.

[forms][bugfix] Fix GeometryType in QuadratureRuleKey exported by Forms::Coefficient

See merge request !261

Both, the function space basis interface and the virtual function
based grid/differentiable function interface have been deprecated
for a long time and are now finally removed. As a consequnce all
code for supporting this interface can also be removed.

Here the old basis/function interfaces are not exposed
but only used internally and can be replaced easily.

[doc] Immprove documentation of AffineConstraints class

See merge request !262

So far a `Forms::Coefficient` exported a `QuadratureRuleKey` with
`GeometryType` being `none` with appropriate dimension. This works
when assembling linear and bilinear forms, because we always multiply
with at least one unary operator which then sets the correct `GeometryType`.

However, if we want to use the nullary operator `Forms::Coefficient`
standalone, e.g. to simply integrate it (it's a grid function after
all), we silently use the wrong `GeometryType`. Luckily we can always
derive the correct `GeometryType` from the element this function is
bound to allowing for an easy fix.

[examples] Add examples with Hermite-type bases

See merge request !238

This adds three examples:

* 2d Poisson equation with cubic Hermite-basis and weak enforcement of
  Dirichlet BC (Nitsches method).
* 2d Poisson equation with cubic Hermite-basis and strong enforcement
  of Dirichlet BC utilizing the `FunctionalDescriptor` interface.
* 2d biharmonic equation with nonconforming Morley basis and strong
  enforcement of clamped BC utilizing the `FunctionalDescriptor` interface.

[cmake] Do not add python flags unconditionally

See merge request !260

This add a patch from !239
and also removes some 2.7 backward compatibility code, since we only
support dune versions >= 2.9 which all require Python3.

Add utility function writeBasis()

See merge request !259

This plots writes all basis functions as vtk sequence
for viewing them with paraview. This is _very_ helpful
when investigating/debugging a dune-functions basis
and affine constraints e.g. for hanging nodes, Dirichlet
BC, ... .

Ideally this should be part of dune-functions, but the
latter does not depend on dune-vtk and furthermore does
not know about constraints so far.

Add constraints support for dune-functions basis

See merge request !258

The examples requires a fix that is not contained in 2.10
and makes composed grid functions work with bound unary
operators.

In order to demonstrate the (hanging-node) constraints
work with higher order bases, too, use 2nd order FEM
as ansatz space and modify the problem such that the
boundary data are not representable exactly in the FE
space.

As extension space we use 4th order finite elements.
By fixing certain DOFs we still get incremental
bubbles wrt. to the P2-basis.

This makes the rendering of Latex more consistent
with the rest of the documentation and improves readability.

Document what exactly `AffineConstraints` is supposed
to do and how it is intended to be used and rename
`constrainMatrixPattern()` to extendMatrixPattern()`
since this in fact enlarges the pattern and never
reduces it.

This avoids having to construct a boundary patch if we want
to process the whole boundary anyway.

If we have `markBoundaryPatchDofs()` there should also be
`markBoundaryDofs()` to avoid having to construct a `BoundaryPatch`
in the trivial cases.

* Adjust to updated interface of `AffineConstraints`.
* Separate construction of constraints object from
  computation of its content.

Before the class only supported linear constraints.
By adding support for constant offsets, this can now
be used e.g. for hanging node constraints (linear),
Dirichlet constraints (constant), or both at once.