The new "emergency" feature in memory.c tries to free memory when it runs out.

To avoid coupling it with value.c by calling clear_free_list directly, I did it
as a function pointer which we initialize by calling beg_value.

I've long thought I would need to do this, because my free_list is only cleared
lazily as new values are allocated.  If a very large string goes on the free
list, it can get "buried" under a bunch of other freed values, and thus linger
indefinitely.  Now with the emergency feature, if the program runs into the
memory limit, it will now clear the free list and finally free any such large
buried string.

When I added that big string test to test/a1.fxl, which creates a string of
length 16,777,216 bytes, I ran straight into that "buried free string" issue.
The big string test itself ran just fine, but then the string went on the
free list and then got buried by subsequent free values.  Then shortly after,
the program ran out of memory.  The emergency feature fixes that.

I considered freeing atom data right away when something goes on the free list,
but even that doesn't completely address the problem solved with the emergency
feature.  You could have a large number of A-values on the free list, and
suddenly need to allocate a large string.  The emergency feature would kick in
and free all those A-values, giving you enough memory for the new string.

In case you're wondering why I did a lazy free list in the first place, it's
quite simple.  If you try to free a deeply nested tree recursively, you can run
out of stack space and get a segmentation fault.  That's unacceptable.  Also,
the lazy non-recursive recycle routine should give you better responsiveness.

Incidentally, I noticed that die.c included memory.h for no reason, so I
removed that.

Oh, and I renamed the "pow" (exponentiation) function to "^".