Revise layout of coordinate data in Python interface

[garth-wells]

We have a bit of a muddle with the layout of coordinate data in the Python interface. The background is:

1. In the C++ layer we normally work with shape (num_points, gdim) and row-major storage
2. From Python it is often natural to have shape (gdim, num_points). The allow a natural syntax for vectorised NumPy operations by coordinate component, e.g. x[1] *= 2.0 multiplies the y-component of all points by 2.

Should we make the layout consistent in the Python interface? Should the shape be (gdim, num_points) throughout?

See related issue #2535.

[jorgensd]

I guess the issue is that a lot of the functions in C++ are not vectorized. It would mean a lot of strided views of data in: https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/geometry/utils.h https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/geometry/gjk.h I guess it will have an effect for assembly as well, however, there we already do a strided copy: https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/fem/assemble_scalar_impl.h#L49-L54

[garth-wells]

I guess the issue is that a lot of the functions in C++ are not vectorized.

The main change would be copying of data between layouts inside the pybind11 layer, but not necessarily in performance critical parts.