This time only for sumfact, as we need direction dependency.

Which play well with the latest change to not assemble on the overlap.

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.

So far, it had to restore indexing information on the visitor
for the second branch. This can be avoided by index pushdown,
just as we do with the sum of two tensors.

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

Otherwise debugging of nonlinear problems becomes hard.

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

It spares us some hassle with function manglers.

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.