Changes

I fixed a bug in the generalized grid test code that was resulting
in pdf_implicit_coefs_terms scalar variables not being read in
correctly for the flipped (descending) grid.

Improved some error handling in clubb_driver.F90

Fixed an issue where ascending and descending grids were producing
results that were not bit-for-bit to each other where centered
discretization was used. The issue occurred because 3 or more terms
were being added together in opposite orders between ascending and
descending grids. This fix ensures terms are added in the same order.

Commiting changes to keep calculation order the same for additions
involving at least 3 terms from different vertical levels between
ascending and descending grids.`

I removed bugs that were causing failures of the bit-for-bit
matching test (at -O0 optimization) between ascending and descending
grids. This group of fixes related to the code that calls pdf_closure
twice and calls the trapezoidal rule code.

I have fixed the ascending vs. descending grid error for the situation
where l_partial_upwind_wp3 is enabled.

I am removing the flag setting of l_mono_flux_lim_thlm to .false.
in flag group 15 of the ascending vs. descending grid tests.

Problem: Removing the constraints on thlm was causing one case (MC3E)
to blow up with a floating point exception in Morrison microphysics.
The issue was that a spike caused an extremely cold temperature to be
found. There is a line of code that takes the difference between
freezing/melting point temperature (273.15 K) and the temperature
at the grid level or sample point, multiplies it by constant, and then
takes EXP to that product. The large difference between temperature
and freezing/melting point, owing to the spike, caused a numerical
overflow to occur and the case to fail with a FPE.

Solution: There isn't any relevant code found in the monotonic flux
limiter that doesn't get tested if l_mono_flux_lim_thlm remains at
a setting of .true. The other parts of conditionals are covered
by setting l_mono_flux_lim_rtm to .false. The only parts of the
code unique to l_mono_flux_lim_thlm are the recording of stats
related directly to thlm. Thus, it makes sense to keep
l_mono_flux_lim_thlm set to .true. for the stability of the run
while turning off the other monotonic flux limiter flags.