Mesh performances and robustness

Some elements still limit GEOSX in some practical cases.
Refactoring https://github.com/GEOSX/GEOSX/pull/1418 should make their fixing easier.

• All mesh mappings are computed (the "nodes to faces", "elements to faces" mappings...).
  This is surely useless for some solvers. Multiple solutions are possible (lazy computing, let the solvers tell what they need).
• Over allocation is hardcoded and done in any case. See for example CellBlockManagerABC::maxEdgesPerNode or CellBlockManager::getFaceMapOverallocation. This user should be able to decide, based on his mesh or on the physics he wants to use.
• Allocations and computations of the mesh mappings are not specialized by ElementType. That could allow the independant computations of the maps (in view of lazy computing) and accelerate that step if a bottleneck for billions of cells.
  See https://github.com/GEOSX/GEOSX/issues/899 for example.
• In a similar way, there exists one unique implementation of CellBlockManager for all meshes. A dedicated implementation could benefit from the specific geometry of InternalMeshGenerator to reach blazing-fast performances (if that matters).
• The 2 implementations of MeshGeneratorBase::importFields (in PAMELAMeshGenerator and VTKMeshGenerator) depend on ElementRegionManager, ConstitutiveBase... which are no geometric concepts. This hinders testability, makes this code responsible for more things that what it should be (a meshing object should not have to know how to navigate in the constutive models).
  For the moment the implementations of MeshGeneratorBase::generateMesh do not suffer from this, but the current design still makes it possible. We should have a protective design.
  Addressed by issue https://github.com/GEOSX/GEOS/issues/2209
• Selectively add a few integrated test using VTK.
  Addressed by PR https://github.com/GEOSX/GEOSX/pull/2268
• Implement a PrecomputedCellBlockManager that would read data from disk and could prevent from recomputing everything every time.
• Be sure that the recent CellBlockManager refactoring does not let temporaries in memory. (Destructors are indeed called so it should not be.) The CellBlockManager is deleted when it becomes useless.

Poke @jeannepellerin

Review the unresolved checklist around CellBlockManagerABC, CellBlockManager, MeshGeneratorBase::importFields, PAMELAMeshGenerator, and VTKMeshGenerator, then read PR 1418 and issues 899 and 2209 for context. The issue is an umbrella for several architectural and performance changes; work is done only when a specific remaining item has defined scope, tests, and measurable completion criteria.