Refactor integrals storage in fem::Form

As exposed in https://github.com/FEniCS/dolfinx/pull/3740, integrals are stored as
```cpp
std::map,
integral_data>
```

1. Subdomain index is a tag integer given to the integration measure, usually in UFL, e.g. `dx((42,))`. The default one for whole mesh is `-1`.
2. Kernel index numbers callable kernel functions per same subdomain index, per same "form" (same form modulo different cell type), according to docs in https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/fem/Form.h#L375. There could be more kernels per one subdomain ID in mixed cell type meshes. In the form constructor this number is however called `form_idx`, see https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/fem/utils.h#L550 and its meaning is it is the index of the form in the provided list of forms. I suppose for `n` cell types in a mesh we provide vector of `n` forms here, so the kernel index refers to the cell type, which is a third name found for this integer, see https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/fem/Form.h#L602.

As the above linked PR shows, there could be duplicate keys in the `std::map` required, because there could be more values (`integral_data`) needed for the same key triple (integral type, subdomain id, kernel id), as the example there shows. This questions the use of `std::map` as a right data structure.

One possible fix is to redesign the integrals storage as flattened
```cpp
std::vector>>
```
Possible examples:
1. `[(IntegralType::cell, -1, 0, integral_data)]` would mean: integrate over all cells, use 0th kernel from the list of forms,
2. `[(IntegralType::interior_facet, 42, 2, integral_data)]` integrate over interior facets tagged as 42, use 2nd kernel (2nd cell type).

However, in this approach, lots of information is redundant, since -1 already encodes that we need to assemble over all cells, and is repeated in cell indices within integral_data. This is more apparent for custom kernels where one provides integral data and the ids could be arbitrary.