Revise `IntegralType` in FFCx and DOLFINx

[jorgensd]

Describe new/missing feature

As raised in #3900 the existing way of defining an IntegralType through an enum is not really extensible to all subentities of codimension (0, 1, ..., tdim).

Instead, and integral should be specified by:

1. Its codimension 0, 1, 2, 3 (cell, facet, ridge, peak)
2. The number of neighbouring cells in the integral
   • 1 for dx, ds, dr, dp
   • 2 for dS
   • M for any other integral over an interior cell.

With a redesign where FFCx passes introduces these for each integral in the form, we could still group them by codimension (0, 1, 2, 3), which would group all ds and dS integrals together.
These should then inside DOLFINx be accessed by checking the corresponding variable num_neighbours, to pick the relevant packing and assembly routines (these should be templated so that we only have one routine for all cases).

FFCx

This means that alot of logic has to be revised as there are many implicit assumptions on integral types coming from UFL aligning with those in DOLFINx/FFCx.