Interface to avoid exposure of solver internals in usage of `get_node_variable`

[tristanmontoya]

Using get_node_variable to save extra node variables in the SaveSolutionCallback currently requires implementing an iteration over nodal values and/or directly accessing the containers:

• https://github.com/trixi-framework/Trixi.jl/blob/main/examples/p4est_2d_dgsem/elixir_navierstokes_vortex_street.jl
• https://github.com/trixi-framework/Trixi.jl/blob/main/examples/t8code_3d_dgsem/elixir_euler_ec.jl
• https://github.com/trixi-framework/Trixi.jl/blob/main/examples/tree_2d_dgsem/elixir_euler_blast_wave_amr.jl
• https://github.com/trixi-framework/Trixi.jl/blob/main/examples/tree_2d_dgsem/elixir_euler_vortex_amr.jl

As suggested here by @DanielDoehring, this could be streamlined so that only the pointwise transformation of solution variables (and possibly gradients, if available in the parabolic cache) needs to be implemented. Possibly related: #2854.

[DanielDoehring]

It probably also makes sense to relabel this to get_nodal_variables (or get_extra_nodal_variables) to further reduce confusion with get_node_vars

[tristanmontoya]

I like get_extra_nodal_variables for this. Now unfortunately we might have to disambiguate extra vs. aux variables, but that's a separate issue.

[DanielDoehring]

I also realized we have get_element_variables which was most likely there before the node version. So maybe we opt for get_nodal_variables to distinguish this.

[tristanmontoya]

I am not sure nodal vs node is particularly helpful to distinguish the two on its own. Maybe calling them "output variables" as in element_output_variables and nodal_output_variables or something like that makes more sense? That also avoids the possible confusion between auxiliary and extra node variables. Or "extra output variables" if we want to be more verbose/specific.

[ranocha]

output_variables (in both cases) looks reasonable to me 👍