The big size of coordinateoperation.cpp could require significant amount
of RAM to build it with -O2 level, and cause compiler crashes in some
environments.

This is aimed at detecting running a PROJ version against a proj.db that is not
meant to work with it. This happens sometimes in complex setups mixing PROJ
versions. Hopefully this will help spotting the issue earlier.

as CompoundCRS with a VerticalCRS being an ellipsoidal height, which is
not conformant. But needed for LAS 1.4 that only supports WKT1

This is a partial backport of https://github.com/OSGeo/PROJ/pull/2450,
with only the new ALLOW_ELLIPSOIDAL_HEIGHT_AS_VERTICAL_CRS=YES option
of proj_as_wkt()

Corrected formula given by @evanmiller

Currently the output of the cct utility is different between radians
and degrees (as expected by cct), because of a bug in cct:

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
  1.0000000000    2.0000000000        0.0000        0.0000

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
       1.0000         2.0000        0.0000        0.0000

The arguments to the printf format string are as follows:

 * radians: width 14, precision 10
 * degrees: width 13, precision  4 (this is by mistake. bug!)

After the suggested fix has been applied, output will be the same for
both radians and degrees:

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
  1.0000000000    2.0000000000        0.0000        0.0000

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
  1.0000000000    2.0000000000        0.0000        0.0000

The cause of the bug is that cct does test if it "has radians to output",
but "neglects" to test if it "has degrees to output", resulting in using
different arguments to the printf format string in the latter case.

The fix makes cct test if it "has either radians or degrees to output".