Improve separation between business and geometry in mesh generators

Describe the issue

Currently, the mesh generation tools depend on business domain, for example by looping over the constitutive relations of the sub regions when importing the fields. Fixing the blurred lines will help future developments and validations.

Proposed cleanup

In MeshGeneratorBase (and especially in its implementations):

For a first PR (Done in https://github.com/GEOSX/GEOSX/pull/2212).

[x] Split importFields into business and a geometry part.

As a second step, split generateMesh into business and geometry part (Done in https://github.com/GEOSX/GEOS/pull/2272).

[x] Keeping the CellBlockManager* in the mesh/generator folder, and the DomainPartition, MeshBody in the business part.   The refactoring for VTKMeshGenerator and InternalMeshGenerator looks quite identical and within close reach.  
[x] The work for InternalWellGenerator may be a tad more challenging because WellElementRegion are directly created in the Generator, without the help of any CellBlock or FaceBlock like we do for the other types of (sub) regions. To be studied with care.

As a last architecture potential refactoring.

[ ] Challenge the CellBlocABC::getExternalProperties feature. Is it relevant w.r.t. MeshGeneratorBase::importFields?

On a more C++ technical point of view for a last PR (and during the continuous refactoring process).

[ ] Be sure that all the remaining business includes (core + tests) are removed.
[ ] Split the generator folder into its own cmake target, with the appropriate dependencies. Can we only expose the *ABC classes and a few utility classes?
[ ] Remove the cmake dependencies (core + tests) .
[ ] See what we can do with the public/private/interface feature proposed by cmake.
[ ] Search for the Region word in the generators folder to check if its the appropriate wording.
[ ] Update the unit tests accordingly.

GEOS-DEV / GEOS

Improve separation between business and geometry in mesh generators #2209