[PATCH] Honor LC_NUMERIC environment variable on Windows

Hi,

While running the TAP tests on Windows with the system locale set to
Russian, I found that frontend programs don't honor LC_NUMERIC from the
environment.

PostgreSQL::Test::Utils explicitly sets:

$ENV{LC_NUMERIC} = 'C';

but pg_test_timing still produces output such as:

Average loop time including overhead: 21,30 ns
Observed timing durations up to 99,9900%:

instead of using a dot as the decimal separator.

This is not specific to pg_test_timing. For example, psql also fails to
parse decimal arguments such as:

\watch 0.01

when the Windows user locale uses a comma as the decimal separator.

I reduced this to the behavior of the Windows CRT. With the environment:

LANG=C
LC_ALL=C
LC_NUMERIC=C

a small MSVC test program shows that:

setlocale(LC_ALL, "");

selects the Windows user locale (Russian_Russia.1251), with "," as the
decimal separator. Calling:

setlocale(LC_NUMERIC, "C");

explicitly afterwards restores the expected "." separator.

For comparison, on Linux I checked the locale selection behavior:

LANG=C -> "."
LANG=C, LC_NUMERIC=ru_RU.UTF-8 -> ","
LC_ALL=C, LC_NUMERIC=ru_RU.UTF-8 -> "."
LANG=C, LC_NUMERIC="" -> "."

The attached patch keeps the existing Windows behavior when LC_NUMERIC
is unset or empty, but explicitly applies a non-empty LC_NUMERIC
environment setting after setlocale(LC_ALL, "").

With the patch, pg_test_timing uses "." when LC_NUMERIC=C, and psql
correctly accepts decimal \watch intervals under a Russian Windows
system locale.

Tested on PostgreSQL master (20devel), Windows 11, MSVC 19.44.

Regards,
Andrew