by introducing an order on the kernel objects and
using the first n kernels instead of an itertools.permutations
generator

We will need even more "levels" in the near future

So far, it did not set the qp tuple correctly and
thus sometimes resulted in too big numbers being
chosen.

Instationary stuff not fixed so far.

Now working apart from iteration order deterministicness

will be superseded by our actual model anyway.

Still not beautiful...

It always aims for maximally horizontal vectorization
where possible.

By using loopys group mechanism. Each sum factorization kernel
defines a group that conflicts with all other sum factorization
groups.

Conflicts:
	python/dune/perftool/sumfact/realization.py
	python/dune/perftool/sumfact/vectorization.py

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.

Make anisotropic quadrature order possible for non DG examples.

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.