Non-fastdg: Permutation of the input happens before the sum factorization
kernel when we setup the input. This is done by a method of the corresponding
interface class.

Fastdg: In this case the input will always be ordered according to x,y,... This
means the permutation needs to happen in the sumfact kernel. Since we want to
vectorize sumfact kernels with different input permutation in an upper/lower
way we need to do this permutation in the corresponding interface class. This
is done in the realize_direct method and in the vectorized case the
corresponding methods of the scalar sumfact kernels are called.

So far only for fastdg. This should also happen in the non-fastdg case.

Note: They are not yet used but in the long term the permutation should be
handled here since it is about input/output setup.

Avoid explicit doubles.

Avoid explicit doubles.

I was tired of the amount of ifs that changed behaviour
depending on stage 1 or 3. This is a cleaner approach.

for further extension

Instationary stuff not fixed so far.

The previous changes to directly pass the visitor
into the coefficient handler was messed up in one place
- only being triggered by the downstream maxwell example.

When doing jacobians of nonlinear systems, the inames used for
a given sum factorization kernel output depend on the accumulation
context.

Save all stage 1 sum factorization kernels that are used in
accumulation expression in the cache during the dry run. Discard all
inactive sum factorization kernels in decide_vetorization_strategy.

We recently learned that usage of sub_elements in UFL is ambiguous...

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 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.