feat: add PermeabilitySpecification as an high-level FieldSpecification

[kdrienCG]

(Previously #4012)

This PR proposes to add an easy way to add higher-level components that create FieldSpecifications without the boilerplate.

---

As an example, to define the permeability you have to specify 3 differents FieldSpecifications.
One for the x-axis, a second for the y-axis, and a last one for the z-axis.
There is also some implementation details that could be hidden, like the component XML attribute for example.

<FieldSpecifications>
  <FieldSpecification
      name="permx"
      component="0"
      initialCondition="1"
      setNames="{ all }"
      objectPath="ElementRegions/reservoir"
      fieldName="rockPerm_permeability"
      functionName="permxFunc"
      scale="9.869233e-16"/>

  <FieldSpecification
      name="permy"
      component="1"
      initialCondition="1"
      setNames="{ all }"
      objectPath="ElementRegions/reservoir"
      fieldName="rockPerm_permeability"
      functionName="permyFunc"
      scale="9.869233e-16"/>

  <FieldSpecification
      name="permz"
      component="2"
      initialCondition="1"
      setNames="{ all }"
      objectPath="ElementRegions/reservoir"
      fieldName="rockPerm_permeability"
      functionName="permzFunc"
      scale="9.869233e-16"/>
</FieldSpecifications>

With this PR, their would be a PermeabilitySpecification component that would create behind the scene those three FieldSpecifications to keep full compatibility with other parts that rely on FieldSpecificationBase. One could think of PermeabilitySpecification as a blueprint or recipe to create FieldSpecificationBase objects.

Here is how it looks like for PermeabilitySpecification:

<FieldSpecifications>
    <PermeabilitySpecification
      name="perm"
      setNames="{ all }"
      regionNames="{ reservoir }"
      fieldName="rockPerm_permeability"
      functionName="permFunc"
      scales="{9.869233e-16, 9.869233e-16, 9.869233e-16}"/>
</FieldSpecifications>

---

The following architecture is proposed:

This way, similar components could be added by providing a data class (like PermeabilitySpecification) and a factory with a generate method to describe how to transform the high-level components into one or multiple "low-level" FieldSpecificationBase.

[rrsettgast]

Hi @kdrienCG
This is something we have been meaning to get to for a while. But not just for perm. Can you implement a generalization to allow for processing and application of arbitrary tensor inputs? There are many things that this would be useful for besides permeability. I think we could read in a "scale" as any array type, and apply appropriately. Then this could be used for stresses, displacements, or any other non-scalar field without multiple FieldSpecificaiton blocks.

[kdrienCG]

Hi @kdrienCG This is something we have been meaning to get to for a while. But not just for perm. Can you implement a generalization to allow for processing and application of arbitrary tensor inputs? There are many things that this would be useful for besides permeability. I think we could read in a "scale" as any array type, and apply appropriately. Then this could be used for stresses, displacements, or any other non-scalar field without multiple FieldSpecificaiton blocks.

Hi @rrsettgast , and thanks for the suggestion
I agree there should be a generalized way to do this, beyond permeability.

I propose doing that in a follow-up PR so we can keep this one focused on specialized components and easier to review.

I've also put together a prototype to test the generalized approach, I can open a separate PR so we can agree on what its interface should be.