Move Mesh.save logic to a separate module

[kinnala]

I think it would make sense to move this logic to skfem.exporters or similar:

scikit-fem/skfem/mesh/mesh.py

Line 262 in fb542a7

def save(self,

Also, there isn't always 1-to-1 mapping with the solution+mesh and their representation in a specific format (such as VTK). Maybe we should make this explicit, i.e. export using a combination of a solution vector and a GlobalBasis object, and make the conversion to a representation such as VTK happen automatically if there will be no loss of information, and display a warning if the conversion required interpolation/projection.

[gdmcbain]

+1 for skfem.exporters though I think we should continue to use meshio where possible and aim to fix or extend it elsewhere. In some cases it's true that different formats aren't isomorphic but often it's meshio that is incomplete. I think we get a multiplier for doing the work there rather than here, where possible; more people using, testing, and reviewing the code, writing extensions, updates, optimizations, &c.

[gdmcbain]

A possible exception to that thinking, which would particularly justify the skfem.exporters package, is for formats which have Python APIs which are eschewed by meshio (to avoid dependence). There might be cases where these offer advantages over meshio (faster, more complete, more authoritative, access to specific functionality beyond mere conversion, e.g. VTK, Gmsh).

[gdmcbain]

A partial lightening of the burden of dependencies incurred with meshio was achieved with the eschewal of the lxml package for writing XDMF in nschloe/meshio#613.

[kinnala]

Should be moved to skfem.io after #305 is merged.