[GeoMechanicsApplication] Expose missing processes and schemes to GeoMechanicsApplication C++ workflow

[carloslubbers]

📝 Description
This PR enhances the GeoMechanicsApplication by adding missing process registrations in the dgeosettlement workflow and expanding scheme factory support for additional scheme variants.

This change allows the dgeosettlement workflow to act more as the generic c++ interface for running geo models in Kratos. This will be applied in the cloud runner PoC through GiD.

🆕 Changelog
Added registrations for the following processes:

• ApplyComponentTableProcess
• ApplyConstantPhreaticMultiLinePressureProcess
• ApplyFinalStressesOfPreviousStageToInitialState
• ApplyInitialUniformStressField
• CalculateIncrementalMotionProcess
• CalculateTotalMotionProcess
• GeoApplyConstantScalarValueProcess
• SetMultipleMovingLoadsProcess
• ApplyWriteScalarProcess
• ApplyCPhiReductionProcess
• ApplyConstantInterpolateLinePressureProcess
• SetAbsorbingBoundaryParametersProcess

Added support for 7 scheme variants:

• BackwardEulerQuasistaticUPwScheme - Backward Euler with U-Pw coupling
• BackwardEulerQuasistaticPwScheme - Backward Euler with water pressure only
• NewmarkDynamicUPwScheme - Newmark dynamic analysis
• NewmarkQuasistaticUPwScheme - Newmark Quasi-Static undamped
• NewmarkQuasistaticDampedUPwScheme - Newmark Quasi-Static with damping
• NewmarkQuasistaticPwScheme - Newmark Quasi-Static water pressure only
• LoadSteppingScheme - Load stepping for static analysis
• GeoMechanicsStaticScheme - Standard static analysis

[WPK4FEM]

Dear Carlos,

First of all the title of this PR is misleading to me. The processes and schemes are present in GeoMechanicsApplication, it is predominantly exposing them to settlement that is changing here.

Settlement and flow are so far deliberately kept to a minimal implementation that only exposes the functionality for a specific type of analysis. This PR is the opposite of that and requires a strategic discussion with PO and team first.

Having that discussion first is the change that I'm requesting. It at least temporarily blocks merging this PR.

Further:
A Quasi-Static scheme does not have inertia terms ( mass ). Getting rayleigh parameters for it is dubious. Creating a NewmarkQuasistaticPwScheme is also unclear to me. Whether an analysis is transient or steady state for, the here only DoF, Pw is not in the naming.

Regards, Wijtze Pieter

[carloslubbers]

@WPK4FEM Indeed, whether you want to have a generic c++ interface that can support a multitude of calculations, or a set of locked down tailor-made interfaces is up to the team. This PR mostly exists because it is useful for testing out workflows through GiD.

Regarding the two scheme comments, these are mostly just copied from the existing python logic in geomechanics_U_Pw_solver.py / geomechanics_Pw_solver.py.
The rayleigh parameters are retireved for quasi-static schemes on line 181-187 in the U_Pw solver
The NewmarkQuasistaticPwScheme is created in the Pw_solver on line 127-129