FMSLogo Code

Add EVALTEST.RETREEIFYFROMRETREEIFY
This test is constructed such that retreeify_running_proc_body is called from the context of retreeify_running_proc_body via silent_load.

Note that Bug #249 is fixed in FMSLogo 8.6.0.
This was incidentally fixed when Bug #620 was fixed.

Add EVALTEST.SILENTLOADFROMTREEIFY.THROWSERROR
This tests the "silent" aspect of the silent loading from treeify
because the file that gets loaded throws an error.

This was not as silent as I had thought.
The error doesn't stop the treeification, but it prompts
the user to fix the file in the editor.
That may be a bug.

Extend the build system to compile a 64-bit version of FMSLogo on Windows.
This is clumsy (for example, there's a separate obj64 directory instead of reusing obj) but it works.
The only thing that I know didn't port is DLLCALL, which currently throws an error.
Getting DLLCALL to work will require some assembly code to follow the X64 calling convention.

Update the expected test results to include new tests that were added and new bugs that were fixed.

Fix typos in a comment

Add logic to evaluator() to handle when the function/expression is a number.
A number is not runnable and so should act as if the procedure is unknown.
Previously, this threw an error during treeification, but a recent bug fix made it so that treeification never throws an error.
That fix introduced a crash when executing a statement like "(2 1)" because the
downstream logic didn't handle when a number was given as a procedure.
This change restores the previous behavior of throwing a "I don't know how to" error, except that it's now recoverable.

Fix Bug #603; STOP before an unknown procedure no longer throws a "don't know how to" error.
The fix is to delay throwing the error from the treeification process to the evaluation process.

Refactoring: Rewrite EVALTEST.UNKNOWNPROCINMACROLIST to use RUNNONRECOVERABLEIDONTKNOWHOWTOTEST.
A comment says that the logic had been duplicated because RUNRESULT couldn't catch the error that was thrown.
Whatever the problem was, it's not reproducible now.

Refactoring: Change SETSCRUNCH to use flonum_arg instead of numeric_arg.
flonum_arg returns a FLONUM, which is what SETSCRUNCH wants.
It also doesn't have any side effects which change the argument list.

This is part of a larger effort to make the code base simpler by removing unneeded side effects.