3125
3126 - start folding in gc layer

I'm trying deliberately to minimize technical jargon.
I've gotten rid of our manual memory management for now.
We might need to bring it back just to guarantee cleared cells stay
cleared.
3127 - segfault when running tests
3128
3129
3130
3131 - ran top-level through valgrind

Watch out for tests where execution continues past die().
3132 - this segfault was a bitch to debug

When you find a segfault in a statement like:
  os << x;
You assume the problem's with x. And when x is a simple string literal
like "(", you start worrying that maybe your program's running into
undefined behavior, clobbering memory, using an uninitialized variable.
That fear was bolstered by how the error would show up in different
places with a debugger vs without. Sometimes the error would even
vanish.

So I installed valgrind, went over the top-level and then this
directory. Nope, no buffer overruns, no unexpected leaks.

My other obvious hypothesis was that I was somehow calling trace()
inside trace(), but grepping through the trace statements I couldn't see
how that might happen. And even if it did happen, Trace_stream->stream
would just close one stream and write multiple lines to the next one,
right?

But valgrind was telling me that I was reading invalid memory if I
inserted a trace statement inside new_cell, but not if I didn't. And the
invalid read was happening far far away, in build.

And scripting gdb was showing me that calls to trace() were never
recursive. Never when I'm tracing inside new_cell is there a call to
trace further up the stack.

It took me forever to notice the call to new_sym inside
  operator<<(os, cell*)
new_sym calls new_cell, new_cell calls trace, and voila there's the
recursion. It's not an explicit call to trace, but operator<< is holding
on to an ostringstream that's now been deleted, and when it tries to
write to it -- BOOM.
3133 - segfault fixed

Still unclear how we can automatically check that operator<< never calls
trace(). Even indirectly.