feat: support non-scalar valued field specifications

[kdrienCG]

This PR generalizes field specifications to support non-scalar values, notably scales (and so function names).

The following interface is proposed:

<FieldSpecification
   name="perm_wall"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="{ 2.0e-22, 2.0e-22, 2.0e-22 }"
/>

Instead of:

<FieldSpecification
   name="permx_wall"
   component="0"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="2.0e-22"
/>

<FieldSpecification
   name="permy_wall"
   component="1"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="2.0e-22"
/>

<FieldSpecification
   name="permz_wall"
   component="2"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scales="2.0e-22"
/>

This PR also add a regionNames array to make it easier to specify multiple regions.

Considerations

Implementations considerations:

Design choice

I added a separate scales attribute (on top of the already existing scale) and a functionNames attribute (on top of the already existing functionName) to keep backward compatibility with every input files.

The user must choose one way to describe its field specification,
either the scalar way:

<FieldSpecification
   ...
   functionName="func"
   scale="11"
   ...
/>

or the non-scalar way:

<FieldSpecification
   ...
   functionNames="{ func1, func2, func3 }"
   scales="{ 11, 12, 13 }"
   ...
/>

and will not be able to use both at the same time.

Other possible implementations

There are different ways this PR could have been implemented, like:

• completly removing the scalar scale attribute in favor of a non-scalar scales
  • _{It would requires a massive refactor and break every input files (if no solution is found to treat scale="42" and scale="{ 42 }" as the same type)}
• use the blueprint/factory design (from feat: add PermeabilitySpecification as an high-level FieldSpecification #4019) to describe a new non-scalar component that creates multiple FieldSpecification
  • _{It would produce a lot of code duplication to have the same capabilities between all the new components (condensing multiple FieldSpecification in one, having a user-friendly way to specify a region, have similar validations etc.). Where those "high-level"/specialized components could be thin wrappers over this PR for custom validation, documentation, etc.}
• others.