curses number pad handling

This attempts to address the issue on hardfought (as described by K2
on reddit two weeks ago) which happened after updating their terminfo
database.  It's based on the reported workaround of having users force
their terminals to avoid "application keypad mode".  The fixes entry is
my guess at what is happening so could be wrong....

I don't have a numeric keypad so this is untested; it /ought to work/.
NetHack's curses interface is doing it's own keypad recognition when
the curses library returns a multi-char sequence rather than converting
that into corresponding KEY_xxx token.  Numpad keys that the interface
recognizes begin with 2 char 'ESC O' when transmitted as 7-bit sequences.
This adds support for SS3 (as sent by DEC Vtxxx terminals and emulators;
value is single char 'M-O') for 8-bit sequences.

It shouldn't break typing Alt+O but that's something else that I can't
test properly.  Setting nethack's 'altmeta' option and manually typing
2 char 'ESC O' still works as intended.

This is curses-specific; the tty interface is completely unaffected.
[However, the vms port has supported SS3 with tty for decades. :-]

doc/fixes3-7-0.txt

@@ -1792,6 +1792,10 @@ curses: fix an off-by-one error when deciding whether a long line on the
 	bottom line of the message window can fit ">>" (curses' "--More--")
 curses: selecting a partial stack, unselecting it, and then selecting it
 	normally did not reset the quantity to the whole stack
+curses: if user's terminal was set to 'application keypad mode' (DEC VTxxx
+	nomenclature; set via 2 char "ESC =") and the terminfo or termcap
+	entry told the terminal to send 8-bit escape sequences (via 3 char
+	"ESC SPC G"), nethack wasn't recognizing number pad keys
 macOS: Xcode project was failing to build if the path to the NetHack source
 	tree contained a space; the issue was within some shell script code
 	contained within the project