Separate TDyMesh from TDy

[bishtgautam]

Currently, TDy contains data and logic that is pretty intermingled with TDyMesh, the mesh type used by the FV algorithm(s). For testing, it would be nice to factor TDyMesh out of TDy in a way that allows a TDyMesh to be constructed and examined without the whole TDy apparatus. At the same time, we must remember that our FE colleagues don't use the TDyMesh type, so we can't just carelessly move everything over. The DM should still belong to the TDy type, for example.

As a start, I'm going through the TDyMPFAOInitialize function in tdympfao.c and copying mesh-construction-related code into a separate function that serves as a "constructor" for a TDyMesh:

/// Construct a  mesh from a PETSc DM.
PetscErrorCode TDyMeshCreateFromDM(DM dm, TDyMesh** mesh);

Not knowing about all the entanglements between TDy and TDyMesh, I would expect this function to create a new mesh and stuff it into the mesh parameter. After calling this function, I would expect to have a mesh that's essentially ready to use. I know this is likely not the case, but one has to start somewhere. :-)

Similarly, I imagine there could be a "destructor" function that deallocates all of the resources assigned to the mesh:

/// Destroy!!!
PetscErrorCode TDyMeshDestroy(TDyMesh** mesh);

When this separation has been done, and if we adopt the CMocka unit testing approach in #146, I can write some tests to make sure that we're capable of building various meshes with correct topological and geometric properties.

[jeff-cohere]

One difficulty in separating TDyMesh from TDy is the fact that the mesh itself seems to store only topological information--all of the geometric information is kept in arrays within TDy itself. This geometric info is obviously important to both FV and FE methods. The functions that "build the mesh" construct both topological and geometric information, so some care is needed to respect the different owners of that information.

[jeff-cohere]

I don't think we can do this without some major rewiring. As we clean things up a little more, maybe it'll become more obvious how to split responsibilities between DMPlex, the geometry vectors, and our own mesh abstraction.