transl: upward funargs no longer cause lisp errors due to free vars

transl: upward funargs no longer cause lisp errors due to free vars

The behavior of translated upward funargs were inconsistent in Macsyma
and have been broken in Maxima for decades.  See below for more on the
inconsistent behavior in Macsyma.

Translated upward funargs would easily cause lisp errors:

(%i1) f(x) := lambda([], x)$

(%i2) translate(f)$

(%i3) f(5)();
<lisp error>

Now this commit fixes the behavior of translated upward funargs so they
more closely match the behavior of their interpreted counterparts:

(%i5) translate(f)$

(%i6) f(5)();
(%o6) x

The implementation of this is different compared to how it was done
in Macsyma and (very) old Maxima.  You can find some old methods for
this in the code and comments for, say, Maxima 5.0.

In Macsyma the translated case was inconsistent with the interpreted
case.  In the case of my function f above, f(5)() would yield x in the
interpreted case but it would yield 5 in the translated case.

We do not have this inconsistency now:

(%i12) zf(x) := lambda([a], [x, a])$

(%i13) translate(zf)$

(%i14) zf1 : zf(1)$

(%i15) block([x : 'ux], zf1(2));
(%o15) [ux,2]

Here %o15 matches the interpreted case, as it should.  In Macsyma, this
would be [1,2] instead.

Since commit ce1ea1c1 subscripted functions can be translated again,
but they have suffered from this same problem as general upward funargs.
An upcoming commit will further fix subscripted functions so the lambdas
created remember values from the subscripts (without all lambdas
remembering too much, which was the cause of the inconsistent behavior
in Macsyma).

No problems with the test suite, share test suite or rtest_translator.
New tests have been added to rtest_translator which compare the
translated and interpreted results for various cases.