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.

Decision about loop order should be done with autotuning in the end.

This commit includes some ugly code that needs to be cleaned up!

Unix has a hard 256 character limit on filenames. I have no idea
how to work around this except for applying a hash function.

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 unstructured stuff changed the implementation of the parallel key
to depend on the quadrature tuple. This means that we need to make sure
that the state of the quadrature tuple is correctly all the time!

Decision about loop order should be done with autotuning in the end.

This commit includes some ugly code that needs to be cleaned up!

This onleiner makes my richards example faster by 70%.

This fixes a code generation performance bug in sum factorized code.
It also reveals that statistic profiling could be superhelpful to us.