Investigate conservation issues in aquaplanet runs

[LenkaNovak]

In #2399 , we found that the target aquaplanet case exhibits growing water and energy conservation errors (by introducing longrun_aquaplanet_rhoe_equilmoist_0M_clearsky_tvinsolation_slabocean in longruns). We need to understand and correct this leakage and track it in our Buildkite runs, which only track the moist baroclinic wave (sphere_baroclinic_wave_rhoe_equilmoist_conservation_ft64).

Testing numerical integrals

• sum(3d_field) v sum(column_integral_definite!(3d_field))
• within floating point precision, using this code:

  
  using ClimaCore: Operators, Fields, Geometry, Spaces
  using ClimaCore.Utilities: half

ᶜ3d = integrator.p.precipitation.ᶜ3d_rain col_integrated_rain = zeros(axes(Fields.level(Geometry.WVector.(integrator.u.f.u₃), half)))

Fields.bycolumn(axes(ᶜ3d)) do colidx Operators.column_integral_definite!( col_integrated_rain[colidx], ᶜ3d[colidx],) end

sum_from_col = sum(col_integrated_rain ./ Fields.dz_field(axes(col_integrated_rain)) .* 2) sum_direct = sum(ᶜ3d)

## 10-day low-resolution test results

### Float64
- problem: using turbulent fluxes causes severe nonconservation (with mostSF is O(e-5) and without SF O(e-16) )
see `slabocen_test_frierdiff_implicit_ft64_0turbflux` vs 
`slabocen_test_frierdiff_implicit_ft64` [build](https://buildkite.com/clima/climaatmos-ci/builds/16030)
- NB: 
- zero drag error: e-6
- zero lhr, evap: e-16
- zero lhr, evap, init q_tot: e-6
- zero lhr, evap, init q_tot, zero precip: e-16
- zero lhr, evap, init q_tot, ᶜS_ρq_tot[colidx] * e_tot_0M_precipitation_sources_helper(...): e-9

### Other checks
- FT32 (with mostSF is O(e-5) and without SF O(e-7) )
- vert_diffusion v frierson: similar error (e-16 for non precipitating setups)
- moist hyperdiffusion is conservative
- MOST: no substantial error difference between mostSF and bulkSF O

# Summary
- the energy conservation issues only occur in moist setups, namely (and exclusively) where precipitation is nonzero
- the linked PR includes accounting for energy change due to precipitation in the conservation check. This improves the error by 3 orders of magnitude. 
- further possible improvements include writing a more robust conservation checker, independent of the tendency code (e.g., as done in ClimaCoupler.ConservationChecker). Since this includes further development and performance assessment, we leave this for another issue (#2568). 

## Linked PR Components
- [x] tracks precipitation term in conservation_check
- [x] converts precipitation to kg / m2 / s (consistent with evaporation)
- [x] add more diagnostics to the slab ocean experiments
- [x] adds a case with the slab ocean and conservation checks to CI
- [x] modifies the conservation check tolerances to be more stringent

## QA
- [x] CI passes 
- [x] low resol. longrun passes
- [x] AMIP resol. slabocean longrun passes ([build](https://buildkite.com/clima/climaatmos-longruns/builds/1407#018d5560-9d6c-41e0-aa1f-74b8833031f1))

[szy21]

The conservation seems worse after switching to Frierson diffusion, as the check in the most recent build failed, and I think Frierson diffusion is the only relevant change. It might be just there is more precipitation. cc @akshaysridhar.

[szy21]

Another thing: Not related to the failure here, but this line may not be correct for topography.