"stackification" of eval function.

[TyOverby]

Right now we end up using the Rust stack as the Ares stack because the eval function recursively evaluates it's arguments. While intuitive, this has a number of problems.

1. Stack depth is determined by the rust stack. Right now on my laptop, I can't even call (factorial 100) without blowing the stack and crashing.
2. Stack traces (while possible to add to the current implementation) is hard to add intuitively.
3. Library users should be able to customize stack depth.
4. Impossible to add delimited continuations and other control flow modifying forms.

What needs to happen is have our own Vec-based stack that becomes a mirror of all the states that Rustc implicitly adds while using recursion.

[TyOverby]

HAHAHA, ok, (factorial 100) was overflowing the integer multiplication, not overflowing the stack. I was really worried there for a moment.

The rest of the arguments still hold.

[TyOverby]

This is what a flame graph of (fib 20) looks like. While naive Fibonacci will always be slow, I hope we can move a lot of the time spent in this flame graph into a single call that manages it's own stack.