Staggered problem dirichlet/neumann return convention

The following discussion from !2852 (merged) should be addressed:

• @martins started a discussion: (+2 comments)

  I aggree and I also think that there should be some direct traits mechanics.

  However, this issue might also exist for user-defined functions. I think the discrepancy here is between how we actually think of PrimaryVariables and how it is used in the test cases. So maybe using for both situations the name PrimaryVariables might be confusing?

The staggered Navier-Stokes code expects full velocities fluxes (in all dimensions) from the problem. This makes it easier to set boundary conditions for when complex treatment due to the discretization is needed in the background.

The correct sizes are now statically asserted !2852 (merged). Still the problem uses the type names PrimaryVariables and NumEqVector but means different types than the corresponding types specified via properties and used in the assembly. This makes this error-prone and confusing. Moreover, it is currently necessary to overload all such functions inherited from the FVProblem because the type information is not properly propagated into the base class.

One solution would be to overload the functions in the navierstokes problem and actually use different type names such as Velocity and MomentumFlux so that it's completely clear that these are different.

TODO: how does this generalize to more complex models? Is it always only the momentum model affected by this? How to treat the difference with the mass model since both are currently implemented in one class with template switches.

• Also change numeq confusion in boundarytypes and modeltraits for the momentum problem -> !3037 (merged)