[GeoMechanicsApplication] Extract the non-linear geometry functionality (Updated Lagrange) from elements

[rfaasse]

As a developer, I want to extract the non-linear geometry functionality from the elements, such that the element classes are more maintainable and configurable, by only depending on the abstract interface of a newly created non-linear geometry policy.

Acceptance criteria

• All functionality related to non-linear geometries, which could have different implementations (in our case Updated Lagrange, but could be extended) is moved to a separate class using the strategy design pattern see e.g. wikipedia for a bit more info
• The interface of the policy is passed to an element, such that the implementation is hidden.
• All updated lagrangian classes are retained until a better registration mechanism is thought out, but their only function should be creating a version of their base with the correct policy.

Note: For more details, see also the discussion in #12057

We need to understand how important this feature is. Also: what is the cost of delaying this?

[rfaasse]

This needs to be crystallized out regarding the:

1. Extra CalculateOnIntegrationPoints functionality
2. Geometric stiffness matrix (KG)

To be taken up by @avdg81 @WPK4FEM

Geometric stiffness contribution through matrix KG

Nested class UPwSmallStrainElement::ElementVariables has member ConsiderGeometricStiffness. It is set by member InitializeProperties of class UPwSmallStrainElement, by querying the element property CONSIDER_GEOMETRIC_STIFFNESS. However, it appears that this property is not set in any of our tests, and therefore it always defaults to false. Consequently, member CalculateAndAddGeometricStiffnessMatrix is never called when running the small test suite. A similar approach has been followed for the U-Pw diff order elements, which is also not exercised by our tests. It appeared that the geometrically nonlinear behavior can be triggered by setting the "move_mesh_flag" option to true, which updates the nodal positions by adding the displacement field to the initial nodal positions (see member SolvingStrategy::MoveMesh).

In class UPwUpdatedLagrangianElement:

• In member CalculateAll of its base class (UPwSmallStrainElement), the permeability update factor is calculated, whereas here it is not. This may be intentional, since the geometrically nonlinear elements implicitly account for the deformed state, and therefore the effect of the deformation on the permeability is automatically considered. This is not the case for geometrically linear elements, which need a correction to account for this effect.
• In member CalculateAll, we calculate and add the geometric stiffness matrix if needed (depending on the ConsiderGeometricStiffness flag as pointed out above).
• Member CalculateOnIntegrationPoints (for double variables) handles variable REFERENCE_DEFORMATION_GRADIENT_DETERMINANT, which is not handled by its base class. Why not???
• Member CalculateOnIntegrationPoints (for Matrix variables) handles variable REFERENCE_DEFORMATION_GRADIENT, which is not handled by its base class. Why not???
• Member CalculateOnIntegrationPoints (for Matrix variables) handles variable GREEN_LAGRANGE_STRAIN_TENSOR, which is also handled by its base class. However, the implementations differ. Can we remove the specialization from the derived class???

In class UpdatedLagrangianUPwDiffOrderElement:

• In member CalculateAll

Extra CalculateOnIntegrationPoints functionality

In class UPwUpdatedLagrangianFICElement:

• Member function Check can be removed entirely, since it simply forwards the request to its base class UPwSmallStrainElement. It doesn't add anything to it.
• For variable REFERENCE_DEFORMATION_GRADIENT_DETERMINANT, a utility function is called to compute the determinants of the deformation gradients of all integration points. This variable is not covered by the CalculateOnIntegrationPoints members of any of its base classes. Should we move it to class UPwSmallStrainElement, which also implements CalculateDeformationGradients?