Introduce integral type and try to separate ufl concepts from FFCx concepts

[jorgensd]

Following the discussion in: FEniCS/dolfinx#3900
here follows an attempt of separate UFL concepts from FFCx/DOLFINx concepts.

This starts with replacing the integral_type, which we are just taking directly from ufl as a string, with a NamedTuple that contains:

• codim: An integer that is either 0, 1, ...., tdim to represent cells, facets, ridges and peaks, or -1 to represent vertices (for now as they are introduced in FFCx. I believe they should be replaced with peak integrals).
• num_cells: Number of cells the integral is attached to. This indicates if we have an "interior" or "exterior" quantity. Currently this is not used to do anything in UFCx.h, but i believe this is something we should store there, rather than the enum we are currently using (facet, exterior_facet, cell, ridge, vertex). Default value for any IntegralType is 1 neighbour
• is_expression: As the integral-ir of Expression and Integrands are the same, we store this information as an optional bool.
• is_custom: If anyone wants to implement a custom element, it should go through the custom measure (none of the other custom types) for now.

This removes a lot of handwavy interaction between ufl and ffcx, as we convert the integral type as early as possible.
Secondly, it removes the extra argument entity_type, as it should be possible to derive it from the integral-type.

This PR also fixes some other errors encountered when introducing typing to more classes.

[coveralls]

coverage: 83.02% (+0.04%) from 82.98%
when pulling 9b486ff on dokken/integral-type
into 3f46df1 on main.