[GeoMechanicsApplication] Investigate the impact of changing the multi-stages to the new orchestrator

[indigocoral]

Investigation needs to be done on the impact, positive, negative effects of changing our multi-stage tests and workflow to the new orchestrator-based multi-stage. What is the impact on the C++ route? Are we going to keep/support the old method?

Questions to be addressed include:

• What is the minimal set of functionality that needs to be ported from Python to C++ to make orchestrator-based multi-stage analysis available for our C++ workflows (DSettlement and, later, DStability)?
• Which Python tests need to be converted from the current multi-stage analysis approach to the orchestrator-based one? How can we break this set down into smaller, more manageable, subsets? (We have a separate issue for this: [GeoMechanicsApplication] Convert our multi-staged integration tests to the Orchestrator-based multi-stage #13052)
• [How] are we going to deprecate/support the current multi-stage analysis approach? And how are we going to inform users about the orchestrator-based multi-stage analysis? Do we need to write any documentation?

Serialization, which is a key component of the orchestrator-based multi-stage analysis, will be addressed by a separate issue.