gnumeric FTBFS on ppc64el: GNM_const initializer element is not constant

Missing build on ppc64el due to:

In file included from ./mathfunc.h:4,
                 from mathfunc.c:38:
mathfunc.c: At top level:
./mathfunc.h:21:31: error: initializer element is not constant
   21 | #define M_LN2gnum GNM_const(0.693147180559945309417232121458176568075500134360255254120680009493393621969694715605863326996419)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./numbers.h:109:25: note: in definition of macro ‘GNM_const’
  109 | #define GNM_const(_c) _c ## L
      | ^~
mathfunc.c:1130:35: note: in expansion of macro ‘M_LN2gnum’
 1130 | static const gnm_float M_cutoff = M_LN2gnum * GNM_MAX_EXP / GNM_EPSILON;/*=GNM_const(3.196577e18)*/
...

Debian also fails to build on this architecture, for what looks like the same problem:

  https://buildd.debian.org/status/fetch.php?pkg=gnumeric&arch=ppc64el&ver=1.12.53-1&stamp=1663781846&raw=0

The error message is a bit generic, just means the C pre-processor is unhappy with the number and does not recognize it as a valid constant (one that can be stored in static memory).

The real issue here is expressing long double numbers on the ppc64el architecture. There have been other instances of this problem, such as debian bugs #849945 and #946836. These discuss a number of different approaches to the problem that may be worth considering as a long term solution.

This has just now become an issue for gnumeric due to the new Debian change in 1.12.53-1, "Pass "--with-long-double" option to configure (Closes: #1016388)." So since that was just introduced recently, a short term fix might be to drop that change for kinetic.