Improve UserObjectInterface errors

[aprilnovak]

Small modification to UserObjectInterface to throw an error if the type of the user object being grabbed does not match T, as well as a test demonstrating the desired behavior for the fluid properties module.

After discussion with @andrsd, it may be more useful for apps and other users to have this patch directly in UserObjectInterface(as opposed to a new FluidPropertyInterface) because users no longer would need to modify their source files to take advantage of this check. Plus, this error check is pretty general and would likely be useful to all MOOSE objects with user objects.

I wanted to print the type of T to get an even better error message, with

T * dummy;
typeid(dummy).name()

but apparently that's implementation-dependent. So if there's some way to figure that out in MOOSE, I think that'd be great to add to the error message.

Closes #17446 and refs #17512

[moosebuild]

Job Documentation on 3584652 wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Precheck on 6d22d82 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/docs/PRs/17496/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format a256fba899a2d5e189024613933ddba6ab2dd09f

[loganharbour]

Okay, this has led me down a path of frustration with this interface. It's one of those Sunday-morning-clean-up-MOOSE mornings. Will push a rewrite by this afternoon.

[loganharbour]

@aprilnovak Let me know what you think:

*** ERROR ***
/Users/harblh/projects/moose/test/tests/interfaces/userobjectinterface/uoi_errors.i:14: (UserObjects/error_test/uo):
     The provided object "null_uo" of type NullUserObject is not derived from the required type.

     The object must derive from ThreadedGeneralUserObject.

[aprilnovak]

I like it! That's perfect - thanks for the input :)

[loganharbour]

Unfortunately... this has led me down a swath of other error fixing and cleaning. I'll take a break for now and push what I have so we can get this in.

The errors with the previous implementation were that the lower level interfaces (FEProblemBase::getUserObject) do the casting ahead of time when getting the object. Therefore, if they don't match, they just return nothing. This means we need to request the base object from that call, and then we can cast it

Review no longer relevant

[pbalest]

@sallustius and I, we are working on mixture properties and we had to write functions like p_from_blabla_and_x that inherits from fluid properties and not singlephase fluid properties, this "NICE" feature is blocking our development. Any quick fix??? We are up for a delivarable soon any quick suggestion is very much appreciated.

[loganharbour]

@pbalest I'll ping you in a message