Transition solid mechanics actions to deriving from PhysicsBase and accomodate downstream meta-action needs

[GiudGiud]

Motivation

The solid mechanics main actions are currently "Physics" in name and syntax only. They derive from a regular Action class and re-implement everything under the sun that a Physics is meant to inherit from its PhysicsBase parent class.

Another issue is that they have their own custom meta-logic for:

• "merging" several actions with different block restrictions
• being created by a parent meta-action (see nuclear materials classes in Bison)

Those capabilities could benefit other Physics if it were transitioned. It could also help simplify this logic with first class support. The meta action logic seems complicated to me, and from my experience debugging the block restriction PR, it's very hard coded to what the SolidMechanicsPhysics do.

On the other hand, the solid mechanics capabilities would gain:

• interaction with Components as is performed in the ThermalHydraulics module. This will help integrate thermo-mechanics models in plant / loop simulations
• all the capabilities in the Physics system right now (exodus restart in some conditions, defining the preconditioning / more than just variables & kernels, a suite of parameter checks, etc)

Design

Change the base class
Move some code to PhysicsBase and possibly create a "CommonPhysicsBase" class to handle the merging of several Physics.

Impact

Lower maintenance cost as we would not need to implement every improvement in Physics twice in the PhysicsBase and the SolidMechanics side
Lower external contribution support cost