We mistook a tag for an Id here...

It always aims for maximally horizontal vectorization
where possible.

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.

We havent got a nonlinear sumfact test case so far, so this one did not break.
test coming soon.

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.

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

It will be necessary to correctly do fastdg for systems

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 y ar enot properly implemented right now, do not seem
to be necessary and conflict with recent changes in loopy.

The old Python2 vs. Python3 problem: non-deterministic hash produces the best bugs!!!