Closes idaholab#16809

This check was immediately triggered because we add three material
objects per material in the input file, e.g. volumetric, face, and
neighbor face materials. Without the check we are vulnerable to user
error such as defining two materials in the input file that define the
same functor property on a given block. Maybe the best remedy in the
future is to have distinct `FunctorMaterials` that don't get added in
triplicate because there is no functional reason for that in a system
where we are evaluating material properties on the fly as opposed to
having references to triplicate storage

GenericFunctors inherit from FunctorInterface and these
are the building block for constant functors and material
property functors. Variables also inherit from FunctorInterface.

This commit also adds the FaceInfo operator() overload to
the FunctorInterface. This overload takes FaceInfo, Limiter,
and bool element_is_upwind arguments as a tuple to allow
unambiguous creation of face values. Corresponding to this
addition we have created a new getInternalFaceValue overload
in MooseVariableFV that uses cell values, gradient, and the limiter
to compute the face value

With this query we avoid potentially unnecessary gradient
computations for two term and we make the assertion in
one term make sense

- Limiter now takes phi_upwind, phi_downwind, grad_phi_upwind, and
  dCD arguments. The gradient argument is a pointer which allows
  the user to not supply it when it's expensive and when the limiter
  is constant. non-constant Limiters now have to manually call
  Moose::FV::rF themselves
- constant() is a new API that a user can call to determine whether
  they need to supply a gradient (and maybe there will be other
  uses as well)

It's perhaps worth mentioning by now that the current functor
implementation forces a paradigm in which 'interpolated' face
quantities are formed by composing atomic interpolated face quantities,
e.g. interp(u*v) becomes interp(u)*interp(v). I imagine we will
have some debate about whether this is satisfactory. My current
data point is that this change does not impact the order of
approximation error has demonstrated by continued passing of ins
and pins mms tests

But leverage functors to greatly simplify code

This prevents incorrectly adding to the Rhie-Chow element coefficient
when doing upwind interpolation and when on a boundary face where the
adjoining element is downwind with respect to the face velocity

New tests:
- Traditional INSFVInletVelocityBC and INSFVOutletPressureBC
- new PINSFVStrongBC which is an FVFluxBC that leverages functors

It was actually working before but when there are large variations
in density then the velocity distribution is asymmetric which is unlike
the Boussinesq benchmarks that I'm used to looking at (which kind of
makes sense... Boussinesq is only supposed to be applied when density
variations relatively small). So instead of generating Rayleigh numbers
by varying delta T (and consequently delta rho), I generate Rayleigh
numbers based on changing L (e.g. xmax and ymax)

This removes the previous exodiff. This also adds a new overload
of operator() that combines an element, face, and subdomain ID. For
variables we check whether we have dofs on the element, and if not
we create a ghost value using the element across (using the face)
and any Dirichlet information. We use the subdomain ID for ghosted
material properties

We don't want the ability to create functor materials to depend on
material ordering in the input file. Consequently if a consumer
material is before a producer, we must allow the consumer material
to be able to create the functor property instance that will then
be setup by the declarer

Includes
- advection objects
- PINSFVMomentumDiffusion

This also required regolding the wcnsfv test since instead
of using atomic interpolations, like was used when the gold
file was initially produced, we now use the aggregated
interpolations

1. Just takes a single qp. For a variable this just returns the
   elemental moose variable data (element_data->adSln()) indexed at qp
2. The other overload takes a pair with the first of the pair
   corresponding to the element type (element, neighbor, or lower)
   and the second of the pair corresponding to the qp

Some details for this commit:
- Add makeElemAndFace method to FVFluxBC
- Update NS postprocessors to use functor properties
- Update inputs to use functor properties

In brief trials, I have not been able to get the energy equation
to converge at the correct rate. It's actually fully possible that I
simply had not refined the mesh enough yet. But anyway this current
feature branch is not about Euler/Navier-Stokes; it's about introducing
functor properties and solving the mass and momentum equations in a
weakly compressible context is enough of a physics demonstration of
the usefulness of functor properties. Incorporating a weakly compressible
energy equation can be a part of a feature branch more focused
on the `navier_stokes` module

Co-authored-by: Guillaume Giudicelli <guillaume.giudicelli@gmail.com>

- Port all of its code back into FunctorMaterialProperty
- Make MaterialPropertyInterface::getFunctorMaterialProperty return a
  FunctorInterface as opposed to a FunctorMaterialProperty. This allows
  returning a ConstantFunctor for default material properties

Refs idaholab#18685

- Implemented for quadrature point evaluations on elements

In fact this can be quite disastrous. We do not build gtest with
METHODS, so whatever METHOD is first used to build the gtest library
will determine the libmesh library that gets linked. And then when
linking our unit test executable and using any METHOD other than the
METHOD initially used when linking gtest, you'll run into hideous errors
like double frees

Co-authored-by: Guillaume Giudicelli <guillaume.giudicelli@gmail.com>

temp

For now I chose to go with an unsigned int for the time argument.
It corresponds to the solution state. This can be used to query
for old and older variable values and can also be easily used
to determine Real time values by querying `FEProblemBase` (e.g.
`time()` or `timeOld()` methods)

This allows us to create physical quadrature point locations
on-the-fly in `Function::evaluate(QpArg)` such that we can call
`Function::value` with `Point` arguments. This could also allow
us in the future to generate variable values at QpArg locations
on-the-fly if we wanted to remove the pre-suppostion that the
user has correctly init'd the variable before calls to `evaluate`

GenericFunctionFunctorMaterial takes an input of function names and then
evalutes functor material properties by calling through to the same
functor interfaces on the function objects.

Another important change in this commit is that we moved inheritance
of `FunctorInterface` down into `MooseVariableField` which allows use
of `MooseVariableFE` as a functor. Moving this down required adding
some more template syntax into the variable classes since we now have
to support more than just the `Real` instantiation of `MooseVariableFields`.

This commit also changed the coefficient in `FVDiffusion` to be a
functor instead of a regular material property which necessitated some
changes in navier_stokes, ray_tracing, and quite a few moose tests. Some
of the more notable additional changes required to make all tests pass:

- FVPropValPerSubdomainMaterial is now a FunctorMaterial. This actually
  greatly simplified the code since we've baked specificity into our
  residual object functor material property requests, e.g. it's always
  clear what subdomain ID we're requesting the material property for
- Made our two framework level `FVInterfaceKernel` objects use functor
  material properties. This necessitated adding `elemFace` and `neighborFace`
  protected methods to `FVInterfaceKernel`

There were also two tests that were `RunException` tests before with
regular material properties that now fun fine with functor properties.
These two tests now show that we allow the following two new concepts:

- Neighboring subdomain materials can define properties of the same name
  even when the material block restriction doesn't match the physics
  block restriction. This should make production physics inputs like we run
  in Pronghorn much simpler
- material properties using in finite volume calculations can depend on
  material properties that are computed in functor materials that couple
  in finite element variables. This is different because we cannot ghost
  regular materials that coupled in finite element variables. Now there is
  still this restriction: a ghosted material property evaluation cannot
  depend on a finite element variable (indeed we cannot even yet call a
  finite element variable with "finite volume-esque" geometric arguments)
  but this could potentially be changed in the future

Co-authored-by: Guillaume Giudicelli <guillaume.giudicelli@gmail.com>

People should think of this geometric argument as corresponding to the
location in space of the element centroid (created from the face info)
or the neighbor centroid (created from the face info). People *should
not* think of this argument as corresponding to the location of the face
just with inifinitesimal positioning on the elem or neighbor side

A comment that Guillaume made really made me think about the design of
this overload. It needed to be revamped to really take sidedness into
account. So now the SubdomainID argument has been changed to be a
std::pair<SubdomainID, SubdomainID>. This qualitative change now makes
it conceptually sound in my mind to call the ElemFromFaceArg overload in
FunctorMaterialProperty when the FaceArg overload is called. And then we
can do a macroscopic interpolation between the results which is an
ability that others clamored for in the beginning

Do this instead of incrementally resizing by one

…gravity

Co-authored-by: Guillaume Giudicelli <guillaume.giudicelli@gmail.com>

Also clean-up documentation to reflect that fully compressible only
works with a momentum parameter and incompressible only works with a
density parameter and superficial velocity variable set

Removing standalone NSFV and PNSFV for gravity and friction

This revealed what should not have been a surprise: deleting an
object makes any reference access to that object bad access. So
now I use the letter and envelope idiom to allow changing out of
the underlying functor material property type