bug: Definition and use of "unnormalized" scale height in cam-fv is inconsistent

Describe the bug

There are several, related bugs, which I've tried to separate into managable units.
This is the first I'd like to resolve, even though I filed one (#296) before this one.

The vertical coordinate "scale height" is defined as log(ps/p), ps = surface pressure (or some other reference)
and log = natural log ln. This can be written as log(ps) - log(p).
When the difference of 2 scale heights is calculated, the 2 log(ps) terms cancel,
so we could save some computation by defining an "unnormalized" scale height = log(1/p) = - log(p)
and calculating SH1 - SH2 = log(p2) - log(p1) (note the numbers).
But when one of those unnormalized SH is compared against some threshhold height,
like ramping_end, that threshhold must be calculated the same way - unnormalized - which it was not.

This topic was further confused by the misdefinition of unnormalized scale height as "log(p)" instead of "- log(p)"
and the resulting, unnecessary complexity in defining higher_is_smaller, and unintended consequences
in routines that use higher_is_smaller.

1. List the steps someone needs to take to reproduce the bug.
   Set up a cam-fv assimilation using

• vertical_localization_coord = SCALEHEIGHT
• model_damping_ends_at_level = 5
• an obs_seq.out file which has obs at heights above model level 6

2. What was the expected outcome?
   There should be no increments at and above layer 5.

3. What actually happened?
   There are non-0 increments in those layers.
   The unnormalized scale heights of the state variables have values ranging from
   5.88 (log(360 Pa)) to 11.5 (log(99200 Pa)), while the ramp_start (normalized scale height)
   had a value of ~ 3.0 (log(10^5/3500) - .3 ramp_depth).
   It would appear that all of those state variables are in the damped layer,
   but the choice of using unnormalized SH caused higher_is_smaller to be .true. (which it should not have),
   and that caused v_above to test whether the state variables have values less than ramp_start.
   They do not, so above_ramp_start decided that none of them were in the damped layer.
   and so their increments were not damped.

Which model(s) are you working with?

Cam-fv only (all versions of CAM and WACCM(-X))

Version of DART

Which version of DART are you using? Manhattan, all of the versions

Have you modified the DART code?

Only cam-fv/model_mod.f90
I'll issue a pull request shortly on a branch of Manhattan.

Build information

Please describe:

1. The machine you are running on (e.g. windows laptop, NCAR supercomputer Cheyenne).
   Any machine.
2. The compiler you are using (e.g. gnu, intel).
   Any compiler