[ ] Go through system part -> GFS
[ ] Export boundary grid function

It makes the code generation workflow more complicated without
contributing anything substantial

Instationary stuff not fixed so far.

There is way more reasons to interpolate a function into the
solution vector and we cover them with one code path:
* Dirichlet boundary conditions (strong ones)
* Initial conditions for instationary expressions
* Initial guesses for Newton solvers

These might sound completely silly, but they are useful when writing
code generic w.r.t. the number of components

- 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.

So far, we used a global context to tell the normal visitor,
that it is generating for driver code. This was feasible, as
we only had one differing implementation. With more differences,
it is better style to derive from the visitor and implement
the differences there.

It is badly implemented as is and does not offer value over
writing symbolic functions.

Do not annotate FiniteElements anymore, further split driver code

It is badly implemented as is and does not offer value over
writing symbolic functions.

Do not annotate FiniteElements anymore, further split driver code