To comply with latest pdelab.

Make anisotropic quadrature order possible for non DG examples.

- Use TensorProductElement in one example.

- We still use the sumfact option to swicth to the sum factorization
  code branch. This way it is still possible to easily swicth between
  sumfact and non sumfact code.

- Only TensorProductElements with the same degree in all directions
  will work. Anisotropie and adaption of quadrature rule will happen
  in the next commits.

The way we currently iterate over children of mxied elements
was plain wrong for nested mixed elements. The tests that
revealed this will soon follow.

So far, we used a global context to tell the normal visitor,
that it is generating for driver code. This was feasible, as
we only had one differing implementation. With more differences,
it is better style to derive from the visitor and implement
the differences there.

Even if the basis scalar, it is worth to put a shape of (n, 1),
because that is how PDELab thinks about it. Not doing so can have
you end up with mismatches between `Dune::FieldVector<double, 1>` and `double`.

It is badly implemented as is and does not offer value over
writing symbolic functions.

Do not annotate FiniteElements anymore, further split driver code

Conflicts:
	python/dune/perftool/pdelab/driver/taskbased.py

The introduction of FunctionView turned out to be a major problem
with more complicated forms. The original idea was to preserver the
structure of the finite element in a way, that loops over components
of a mixed element are realized by actual loops (treating them with
free indices and such). However, this causes quite some nightmares and
was never implemented as generically as needed (I even doubt that is
possible).

However, there is another option, which is to unroll any such loops
on a symbolic level. While this may sound like a bad idea at first
there is some really positive aspects about it:
* ListTensor and ComponentTensor nodes collapse completely (and would
  otherwise have a big nightmare potential)
* Symbolic zeroes do not generate code - important in hyperbolic problems
  where the system matrices are quite sparse or for axiparallel grids,
  where geometric quantities have many zeroes.
* The compiler would unroll these small loops anyway.
* TSFC (and I guess also FFC) do it the same way.

Implementing this required me to redo the form splitting algorithm.
I rethought it and integrated it into the main ufl->loopy visitor.

though still mixed up by name with dirichlet bc.