A number of fields were being calculated in `advance_clubb_core` (`wp2_zt` `wp3_on_wp2` `wp3_on_wp2_zt` `Skw_zm` `Skw_zt) then passed into other routines, however, all these fields depend on `wp2` and were not being updated after `wp2` was being updated by `calc_sfc_varnce`. This commit fixes that by moving where these fields are calculated - instead of computing in `advance_clubb_core` with the incoming `wp2`, we now calculate them "on-demand" where they are needed using the most recent value of `wp2`.
Using our default flag set, there are no numerical differences caused by this change set, only a few stats differences. There are real differences that occur when `l_upwind_xpyp_ta = .false.` (a clubb_config_flag value) or when `l_explicit_turbulent_adv_xpyp = .true.` (a parameter in model_flags.F90), but these are small differences and do not visually affect plots for our stable cases. Changing the order of the `advance_` routines would also cause this to be BIT_CHANGING, since that also affects the update path for `wp2` - now these values that got moved would be using the newest `wp2` instead of being "stale", also causing small (but real) differences.
* Calculating wp2_zt and wp3_on_wp2 where needed, rather than passing those values around through advance_clubb_core. This is BIT_CHANGING for a handful of stats only variables be default: wp3_on_wp2, wp3_on_wp2_zt, wp3_on_wp2_cfl_num, term_wprtp2_explicit, term_wprtpthlp_explicit, and term_wpthlp2_explicit. Some Skw_ variables when using lmm_stepping, and has actual differences (not just in stats output) when swapping the order of the advance routines
* Moving things around, this seems to all be BFB except for the Skw_ movements, which is BIT_CHANGING if the advance_ order changes
