Fix for GNU hystpdf crash

[mathomp4]

In running GFDL + NH + GF2020 + RRTMGP + GOCART Data runs for @FlorianDeconinck, it was found that GNU runs would fail at C180+ with:

[borgl058:189261:0:189261] Caught signal 8 (Floating point exception: floating-point overflow)
==== backtrace (tid: 189261) ====
 0 0x0000000000016910 __funlockfile()  ???:0
 1 0x0000000001585005 __geosmoist_process_library_MOD_hystpdf()  /discover/nobackup/projects/gmao/SIteam/Models/GEOSgcm-v11.5.1-GNU-SLES15/GEOSgcm/src/Components/@GEOSgcm_GridComp/GEOSagcm_G
ridComp/GEOSphysics_GridComp/GEOSmoist_GridComp/Process_Library.F90:2064
 2 0x00000000016f63e0 __geos_gfdl_1m_interfacemod_MOD_gfdl_1m_run()  /discover/nobackup/projects/gmao/SIteam/Models/GEOSgcm-v11.5.1-GNU-SLES15/GEOSgcm/src/Components/@GEOSgcm_GridComp/GEOSag
cm_GridComp/GEOSphysics_GridComp/GEOSmoist_GridComp/GEOS_GFDL_1M_InterfaceMod.F90:619
 3 0x000000000151e14b __geos_moistgridcompmod_MOD_run()  /discover/nobackup/projects/gmao/SIteam/Models/GEOSgcm-v11.5.1-GNU-SLES15/GEOSgcm/src/Components/@GEOSgcm_GridComp/GEOSagcm_GridComp/
GEOSphysics_GridComp/GEOSmoist_GridComp/GEOS_MoistGridComp.F90:5485
...

Intel runs never had this issue.

The traceback points to this code:

GEOSgcm_GridComp/GEOSagcm_GridComp/GEOSphysics_GridComp/GEOSmoist_GridComp/Process_Library.F90

Lines 2063 to 2064 in e2b79bd

	QAx = 0.0
	if (CLCN > 0.0) QAx = (QLCN+QICN)/CLCN

As the failure is an overflow, the thought is that we have very small or denormal CLCN such that division blows out the 32-bit real. So the proposed solution is to compare against tiny rather than just 0:

                            QAx = 0.0
      if (CLCN > tiny(0.0)) QAx = (QLCN+QICN)/CLCN

Tests show this seems to fix the issue at C180 for GNU.

Tests with this fix at c24 and c48 with BACM_1M show this is zero-diff. I can't always assume this is the case, but it seems enough proof for me to label 0-diff in the sense that "Intel + Release + BACM + c48" is zero-diff.

I'll add @wmputman as a reviewer as he is the first person I think of in re this code. Though maybe @narnold1 might be better? 🤷🏼