Simplify mesh creation interface and algorithms

[garth-wells]

This PR simplifies the interfaces for mesh creation from topology and geometry data, and simplifies many of the associated algorithms. It fixes #2949.

Background

The mesh interface has been complicated by using an adjacency list for cells when we only support one cell type in a mesh, and by having vectors of cell type and element coordinate maps in topology and geometry, and an obscure 'cell offset' array. The current discussion on how to support mixed topology meshes is pointing away from an adjacency list being the appropriate data structure for cells of mesh. The direction of travel is to store different cell types separately. This will make many algorithms much simpler, and it preserves the IndexMap abstraction (which was broken when mixing different cell types in a single data structures.

Next steps

When adding mixed topology support, we should start from the bottom up. The eventual design will inform the appropriate interfaces.

If we need functions like:

/// @warning Experimental interface for ...
const std::vector<mesh::CoordinateElement<T>>& dolfinx::mesh::Geometry::cmaps() const
{ return _cmaps; }

we should do

const mesh::CoordinateElement<T>& dolfinx::mesh::Geometry::cmap() const
{
  if (_cmaps.size() > 1)
     throw std::runtime_error("Geometry has more than one coordinate element");
  assert(!_cmaps.empty());
  return _cmaps.front();
}

to avoid (i) introducing pollution throughout the code and (ii) to give much more robust error handling as we transition to supporting mixed topology.