Perl_sv_vcatpvfn_flags: sort PL_numeric_radix_sv

Perl_sv_vcatpvfn_flags: sort PL_numeric_radix_sv

Under locales the radix point may not be just a simple '.' but a Unicode
string like "\N{ARABIC DECIMAL SEPARATOR}". Currently the hex f/p code
explicitly takes account of the length of this string when calculating the
buffer length, but the other branches don't - they just rely on the
"add 40 fudge factor" to protect them.

Instead, handle its length for all branches, and simplify utf8 handling.
Currently it checks post-format whether the radix point was utf8, and if
so marks the resulting buffer as utf8. Instead, check for utf8-ness at the
same time we check for length.

This new approach doesn't check whether the resulting string actually
contains the radix point string, so in principle the string could be
marked utf8 but not have any >127 chars. I think this is harmless.