Allow MooseObjectAction to extract parameter from its corresponding parent folder

[YaqiWang]

Reason

This small (one-line change) yet possibly controversial feature can be done really easily in Parser as

diff --git a/framework/src/parser/Parser.C b/framework/src/parser/Parser.C
index b267ce9711..b9010312a7 100644
--- a/framework/src/parser/Parser.C
+++ b/framework/src/parser/Parser.C
@@ -367,6 +367,7 @@ Parser::walkRaw(std::string /*fullpath*/, std::string /*nodepath*/, hit::Node *
       {
         object_action->getObjectParams().blockLocation() = params.blockLocation();
         object_action->getObjectParams().blockFullpath() = params.blockFullpath();
+        extractParams(MooseUtils::baseName(curr_identifier), object_action->getObjectParams());
         extractParams(curr_identifier, object_action->getObjectParams());
         object_action->getObjectParams()
             .set<std::vector<std::string>>("control_tags")

This basically allows users to put common parameters shared by for example materials under [Materials] block instead of repeatedly under their own sub-blocks. The feature is better than [GlobalParams] because those params within [Materials] can only been seen by materials. This limited scope can reduce the possibility of naming conflict among different types of objects.

Lots of neutronics models can benefit from this feature because of a number of materials could exist with some common parameters.

Design

This is a completely new feature in the input file and there could be some implications. But conceptually I think this feature is good.

Impact

A new feature.

[lindsayad]

I just found a bug in an input file that I wrote. I repeatedly have this for NSFVKernels:

u = u
v = v

And I found in one of the several blocks that I had:

u = v
v = v

It took me three hours to debug this exodiff haha with all the PETSc monitor options you can imagine: -snes_monitor_solution -ksp_view_pmat -snes_monitor_residual. I didn't consider that the bug could be in my input file instead of in my code. Darn u and v look too similar. Anyway I think if I could have written that a level higher and applied to all NSFVKernels that I probably would have been less likely to make this mistake. One can legitimately argue that this error becomes less likely with an action as well. (And yes I could have also done this with GlobalParams...)

[YaqiWang]

Right, did you add NSFV support in the NS actions? That will be my first thing to do, hehe.

[rwcarlsen]

Action would be ideal. Maybe we need an input file validation tool that does a machine-learning "one of these things is not like the other" check.