In the /sumfact_poisson_dg_3d_unstructured_deg2_symdiff_nonquadvec_gradvec
test case this reduces the time spent in evaluation of it from >100s to 6s.

This just reverts to the old behaviour. The new implementation of loop
reordering doesn't need that anymore.

The SumfactKernel object stores a tuple of transformations that will be
registered in the realization and applied in the localoperator. These
transformations can change the name of the sum factorization kernel
function. This way it should be possible to use autotuning for picking
transformations.

The permutation is already in. Using the numbers requires to have the
correct global state whenever the key is evaluated, which we cannot
guarantee.

The realize_output interface method was not really necessary and just adds a
layer of indiretion.

Introduce different methods for realize_input/output
realize_direct_input/output and setup_input/output. The setup methods cover
code generation outside the sumfact kernel function (creating input array or
accumulating result). realize and realize_direct handle the input/output in the
nonfastdg and fastdg code branch.

Seperate interface methods make it a lot easier to find out where each of those
methods will be applied. Besides that most interface classes need to provide
more that two of those methods anyway...

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.

Note:

- direct_is_possible true/false could probably be handled in an upper/lower
  vectorization way.

- Vectorization of SF kernels should be based on cost permuted matrix sequence.

Needed in dune-perftool-playground for Navier stokes