Emit SymPy code that runs (#909)

[Rafael-SOWNet]

Closes #909, and it turned out to be worse than that issue described — the issue named the unbound names,
and the same file also had a missing parenthesis.

expression	was	is
1/2, 1/3 + 1/6	sympy.Rational(1, 2 — SyntaxError: '(' was never closed	sympy.Rational(1, 2)
0/0, 1/0	NaN — NameError: name 'NaN' is not defined	sympy.nan
+oo, -oo	+oo, -oo — NameError	sympy.oo, -sympy.oo

The parenthesis broke every expression carrying a non-integer rational, which is most of what a
computer algebra system hands back. MathS.ToSympyCode's documented purpose is code you can run in
SymPy, so this was not a cosmetic defect.

Measured by running it

SymPy 1.14 locally, eight expressions emitted and executed. Before: two NameErrors and the rationals
refusing to parse. After: zero failures, and the values come back exact rather than merely valid —

sympy(simplify(1/2))         ran, expr = 1/2         (Half)
sympy(simplify(0/0))         ran, expr = nan         (NaN)
sympy(simplify(x + 1/2))     ran, expr = x + 1/2     (Add)
sympy(simplify(sqrt(2) + pi))ran, expr = sqrt(2) + pi(Add)

Half, not the float 0.5, which is the whole reason to emit sympy.Rational rather than a division of
two Python integers.

What was already right

Checked before touching anything, because the "what else is the same shape" guess was wrong here: pi,
e and i already emitted sympy.pi, sympy.E and sympy.I, and sqrt already emitted sympy.sqrt.
Only the two number cases above were broken.

The tests, without an interpreter in the suite

The suite cannot depend on Python, so the two properties that actually failed are what get asserted:

• the parentheses balance — what sympy.Rational(1, 2 violated;
• every name in the emitted body is bound — declared as a sympy.Symbol in the preamble, or reached
  through sympy. — which is what a bare NaN or +oo violated.

The second generalises: any future value that leaves here as a bare name fails it. 17 of the 23 cases
fail against the old exporter, 23 of 23 pass here.

Not in this PR

1/2 before simplification is a Divf of two integers and emits 1 / 2, which Python evaluates to the
float 0.5 — exactness lost silently. Fixing it means deciding how much to sympify: emitting
sympy.Integer(n) for every integer is faithful but makes x + sympy.Integer(1) of x + 1. That is a
design choice rather than a defect fix, so it is filed separately as #911 with a recommendation.

ToSymPy is reached only from ToSympyCode, so evaluation and simplification cannot see any of this —
verified by grep rather than assumed. Suite 6474 passed / 0 failed, F# wrapper 130 passed, casbench
117/119 with 0 wrong.

Cut from master at 548ea178.