Changing some class/catalog names for coupled simulations

[francoishamon]

Describe the issue Following up on this comment from @klevzoff, I post this issue to know if there is any objection to changing some of our catalog names and class names to have more consistent xml files in the coupled simulations.

Proposed cleanup Changes in catalog names (following Sergey's suggestion below):

• CompositionalMultiphaseFVM -> MultiphaseFlowFVM
• CompositionalMultiphaseHybridFVM -> MultiphaseFlowMimetic
• CompositionalMultiphaseWell -> MultiphaseWell

which will be consistent with MultiphasePoromechanics in coupled simulations. Class names would be changed accordingly.

Change in attribute names:

• solidSolverName -> mechanicsSolverName

in the coupled simulations (as discussed during the dev meeting)

Changes in class names (don't appear in the xml, but still):

• MultiphasePoromechanicsSolver -> MultiphasePoromechanics
• SinglePhasePoromechanicsSolver -> SinglePhasePoromechanics
• SinglePhasePoromechanicsSolverEmbeddedFractures -> SinglePhasePoromechanicsEmbeddedFractures
• FlowProppantTransportSolver -> FlowProppantTransport
• HydrofractureSolver -> Hydrofracture
• LagrangianContactSolver -> LagrangianContact

to have consistent class names between single-physics and multiphysics solvers.

I am open to better naming suggestions of course.

[klevzoff]

One additional thing to consider is adding the word "Flow" (e.g. SinglePhaseFlowFVM and MultiphaseFlowFVM), to be more explicit about the physics being solved. We can argue about multiphase physics technically being FlowTransport, but IMO just Flow in multiphase context always implies transport of species. On the other hand, FlowProppantTransport is more explicit about what is being transported. It's probably going to be impossible to reach 100% consistency.

[paveltomin]

@francoishamon do we want that pain?