Solidify writableCoupledValue API

[dschwen]

Reason

External library routines called from UserObjects can potentially produce a lot of data that needs to go into auxiliary variable fields. writableCoupledValue provides a way to write those fields without temporarily storing the data in maps and assigning them through AuxKernels.

Design

A few additional checks will be required to make this a solid API.

• Only one object should be allowed to get a writable variable reference for a given Variable.
• Dependency resolution should take this API into account. An object that calls writableCoupledValue should register the variable as a provided quantity, and user objects that request a variable should mark it as a required property. The complication here is that we need to ignore any coupled (aux)variables in user objects that are simply updated through AuxKernels.
• Ideally we'd check the variable type (elemental/nodal) to match the corresponding userobject type.

Impact

Simplify updating AuxVariables from calculations in UserObjects. Get rid of a lot of boiler plate code and simplify ease of use.

[dschwen]

Dependency resolution needs to be figured out here. For that MOOSE relies on InputParameters. Basically we'd need to declare coupled variables a written to in the input parameters if we want the execution order to be resolved such that variables written to by one object are available by the next object that would use them. This is a mess. Right now CoupleableMooseVariableDependencyIntermediateInterface puts all coupled variables into a list of needed objects for dependency resolution, however, variables that are written to are provided and should drive the dependency resolution in the opposite direction.

It's frankly a miracle to me that any of this currently works.

[dschwen]

Why is coupling var1 and var2 in MultipleUpdateAux not causing the two SelfAux kernels in multi_update_var_test.i to get executed first? (and thus copying the solution into the dofs before MultipleUpdateAux gets a chance to overwrite them?!