pgsql: Restructure formatting.c's NUM_processor() to add some const-san

Restructure formatting.c's NUM_processor() to add some const-sanity.

NUM_processor() is an under-documented mess. Depending on the value
of is_to_char, it either reads "inout" and writes "number", or
the other way around. That makes it impossible to label either
string "const", which seems like a minimum expectation in 2026.
It also complicates replacing the output buffer with a StringInfo:
we'd have to convert both strings, which is pretty pointless for
the input side.

Moreover, we're buying very little code savings by doing it like this,
since a large majority of the function's code has to be wrapped inside
"if (is_to_char)" tests.

To fix, split the function into NUM_processor_from_char() and
NUM_processor_to_char(), and rename/const-ify arguments as
appropriate. Both paths now read from "const char *input"
and write to "char *output".

This patch doesn't intend to make any algorithmic changes, it's
just mechanical code rearrangement and symbol renaming. The
only real exception is that I got rid of passing "input_len"
to NUM_processor_from_char()'s subroutines in favor of storing
"const char *input_end" in NUMProc.

Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Reviewed-by: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Discussion: https://postgr.es/m/3451175.1786641871@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/28c5d0724875591ff55dd85a065207badc2fa8ad

Modified Files
--------------
src/backend/utils/adt/formatting.c | 933 +++++++++++++++++++++----------------
1 file changed, 521 insertions(+), 412 deletions(-)