Fix octal number arguments in printf integer arithmetic

Bug 1: POSIX requires numbers used as arguments for all the %d,
%u... in printf to be interpreted as in the C language, so
	printf '%d\n' 010
should output 8 when the posix option is on. However, it outputs 10.

This bug was introduced as a side effect of a change introduced in
the 2012-02-07 version of ksh 93u+m, which caused the recognition
of leading-zero numbers as octal in arithmetic expressions to be
disabled outside ((...)) and $((...)). However, POSIX requires
leading-zero octal numbers to be recognised for printf, too.

The change in question introduced a sh.arith flag that is set while
we're processing a POSIX arithmetic expression, i.e., one that
recognises leading-zero octal numbers.
Bug 2: Said flag is not reset in a command substitution used within
an arithmetic expression. A command substitution should be a
completely new context, so the following should both output 10:

$ ksh -c 'integer x; x=010; echo $x'
10            # ok; it's outside ((…)) so octals are not recognised
$ ksh -c 'echo $(( $(integer x; x=010; echo $x) ))'
8             # bad; $(comsub) should create new non-((…)) context

src/cmd/ksh93/bltins/print.c: extend():
- For the u, d, i, o, x, and X conversion modifiers, set the POSIX
  arithmetic context flag before calling sh_strnum() to convert the
  argument. This fixes bug 1.

src/cmd/ksh93/sh/subshell.c: sh_subshell():
- When invoking a command substitution, save and unset the POSIX
  arithmetic context flag. Restore it at the end. This fixes bug 2.

Reported-by: @stephane-chazelas
Resolves: https://github.com/ksh93/ksh/issues/326

NEWS

@@ -3,6 +3,18 @@ For full details, see the git log at: https://github.com/ksh93/ksh
 
 Any uppercase BUG_* names are modernish shell bug IDs.
 
+2021-09-13:
+
+- Fixed a bug introduced in 93u+ 2012-02-07 that caused the 'printf' builtin
+  (and its 'print -f' equivalent) to fail to recognise integer arguments with a
+  leading zero as octal numbers. For example, 'printf "%d\n" 010' now once
+  again outputs '8' instead of '10'.
+
+- Disable the POSIX arithmetic context while running a command substitution
+  invoked from within an arithmetic expression. This fixes a bug that caused
+  integer arguments with a leading zero to be incorrectly interpreted as octal
+  numbers in non-POSIX arithmetic contexts within such command substitutions.
+
 2021-09-12:
 
 - When invoking a script without an interpreter/hashbang path on Linux and