Be more careful about extracting encoding from locale strings on Windows.

 Be more careful about extracting encoding from locale strings on Windows.
 
 GetLocaleInfoEx() can fail on strings that setlocale() was perfectly
 happy with.  A common way for that to happen is if the locale string
 is actually a Unix-style string, say "et_EE.UTF-8".  In that case,
 what's after the dot is an encoding name, not a Windows codepage number;
 blindly treating it as a codepage number led to failure, with a fairly
 silly error message.  Hence, check to see if what's after the dot is
 all digits, and if not, treat it as a literal encoding name rather than
 a codepage number.  This will do the right thing with many Unix-style
 locale strings, and produce a more sensible error message otherwise.
 
 Somewhat independently of that, treat a zero (CP_ACP) result from
 GetLocaleInfoEx() as meaning that we must use UTF-8 encoding.
 
 Back-patch to all supported branches.
 
 Juan José Santamaría Flecha
 
 Discussion: https://postgr.es/m/24905.1585445371@sss.pgh.pa.us