Add form instances to primitives via data handling
Currently the forms are members of the respective operators they are used in.
For some/many cases, however, a probably cleaner solution would be to allocate them at the individual primitives and pull them in the operators via stored data IDs.
Some examples where this would be beneficial/required:
blending: Currently the blending function of the form instance is adapted by the operator on-the-fly. This means that we require action from the operator although only the form is using the blending function, which could be added to the form during construction, per-primitive. This could also be a potential optimization as we could decide that the identity map does not need to be called if blending is not active.
free-slip: Similarly, we will require the normals for each primitive in the stiffness matrix assembly routines for a free-slip implementation. These will likely be constant on each primitive (also in the blending case, where we have a single geometry map per primitive -> single "normal function"). Thus could be added to the forms. Therefore, if not instantiated on each primitive, we would need to modify the operators again.
information about the primitive: In the free-slip case for example, this design could be used to decide in the assembly routines if the element is located on a boundary primitive (also useful in free-slip implementations for example).
This would mean that we need some data handling class implementations for the forms.