Give NaN a token, so its printed form reads back (#906)

[Rafael-SOWNet]

Closes #906, and takes the option both comments there converged on: NaN becomes a reserved word, like
the built-in function names.

expression	was	is
"NaN - NaN".Simplify()	0	NaN
"NaN / NaN".Simplify()	1 provided not NaN = 0	NaN
"NaN * 0".Evaled	0	NaN
"NaN * 2".Evaled, "NaN + NaN".Evaled	left as written	NaN
NaN as a variable name	a variable	the NaN value
NaNx, NaN_1, aNaN	variables	variables, unchanged

Every "was" in that table is the ordinary rewrite for a free variable, which is what NaN parsed to.
Nothing on the page said so, because a variable named NaN prints as NaN too.

Latexize needed nothing, and that is measured rather than assumed

@Happypig375's hedge in the issue — "CSharpMath uses \mathrm{undefined} as the special token here, I
think" — is right, in both directions. AngouriMath has emitted \mathrm{undefined} for NaN all along
(Latex.Number.Classes.cs), and CSharpMath's Evaluation.cs carries

case ("undefined", 0, FontStyle.Roman): @this = MathS.NaN; break;

so the LaTeX round trip was already closed. This PR does not touch Latexize. Its three non-finite
values (\infty, -\infty, \mathrm{undefined}) were all fine; it was Stringize that printed two
names the parser knew and one it did not.

The grammar choice

Declared as a lexer rule above VARIABLE, which is where BOOLEAN sits and for the same reason:
equal-length matches go to the earlier rule, and this word would otherwise be an identifier. +oo and
-oo are inline literals instead, which is safe for them because they cannot collide with a name.

One spelling, NaN. BOOLEAN accepts two capitalisations of each word because it has to read back
its own output — Entity.Boolean prints True where a caller types true — and NaN prints and reads
the same way, so there is nothing to reconcile and no reason to enlarge the reserved surface.

Reserving the word costs the identifier, exactly as mod did in 2.0, and only the exact spelling: the
lexer takes the longest match, so NaNx, NaN_1 and aNaN are all still variables. Syntax.md lists
the new literal.

The round-trip test now runs in both directions

This is the part that catches the next one. Every case in StringizeRoundTripTest began from a
string, so it could only reach expressions the parser already produces — a value with no source form
was invisible to all of them, however many cases were added. That is why the defect lived in an output
for as long as it did.

It now also enumerates the named constants of MathS and Entity.Number.Real by reflection, prints
each and reads it back, so a constant added later is covered without anyone remembering the file exists.
MathS.NaN and Real.NaN are the two that fail against the old grammar, along with the computed cases
(0/0, 1/0, +oo - +oo).

Regeneration discipline

Regenerated with the committed antlr-4.13.1-complete.jar and the AntlrPostProcessorReplacePublicWithInternal
step. The unmodified grammar was regenerated first and its diff confirmed empty, so nothing in the
generated files here is a toolchain difference rather than my rule.

Measured

New tests fail 9 of 219 against master and pass 219 of 219 here. Suite 6451 passed / 0 failed, F#
wrapper 130 passed. casbench 117/119 with 0 wrong, rootcheck 596/596, simpsweep 10463/10463, propcheck
1340 checks with 0 failures, crashcheck 1652 cases with 0 crashes, boundcheck 2 disagreements and 0
that did not parse — worth naming for a grammar change. docsamples has 0 compile errors; its single
output mismatch is the Solvers wiki page that #901 made stale, which I am updating separately.

One more of the same shape, filed rather than bundled: ToSympy for a Real is => Stringize(), so it
emits NaN, +oo and -oo into generated Python whose preamble is only import sympy — none of those
names is bound there. That is #909.

Cut from master at 7c3c01ab.