Fix import of float attribute/value from environment (re: 960a1a99)

Bug 1: as of 960a1a99, floating point literals were no longer
recognised when importing variables from the environment. The
attribute was still imported but the value reverted to zero:

$ (export LC_NUMERIC=C; typeset -xF5 num=7.75; \
   ksh -c 'typeset -p num')
typeset -x -F 5 num=0.00000

Bug 2 (inherited from 93u+): The code that imported variable
attributes from the environment only checked '.' to determine
whether the float attribute should be set. It should check the
current radix point instead.

$ (export LC_NUMERIC=debug; typeset -xF5 num=7,75; \
   ksh -c 'typeset -p num')
typeset -x -i num=0
...or, after fixing bug 1 only, the output is:
typeset -x -i num=75000

src/cmd/ksh93/sh/arith.c: sh_strnum():
- When importing untrusted env vars at init time, handle not only
  "base#value" literals using strtonll, but also floating point
  literals using strtold. This fixes the bug without reallowing
  arbitary expressions. (re: 960a1a99)
- When not initialising, use sh.radixpoint (see f0386a87) instead
  of '.' to help decide whether to evaluate an arith expression.

src/cmd/ksh93/sh/init.c: env_import_attributes():
- Use sh.radixpoint instead of '.' to check for a decimal fraction.
  (This code is needed because doubles are exported as integers for
  ksh88 compatibility; see attstore() in name.c.)

NEWS

@@ -3,6 +3,11 @@ For full details, see the git log at: https://github.com/ksh93/ksh/tree/1.0
 
 Any uppercase BUG_* names are modernish shell bug IDs.
 
+2022-06-03:
+
+- Fixed a couple of bugs that caused floating point variables imported from
+  a parent ksh through the environment to be corrupted.
+
 2022-06-01:
 
 - New 'typeset' feature inspired by bash (and zsh and mksh): the -g flag