Deploy the inline replacement technique, dramatically accelerating the code.

Certain ordinary tests like test/fib are easily 4 times faster.  A large
sorting test is even 18 times faster because it uses more memory due to the
inline replacement of results.  That's an excellent trade-off.

You'll note in parse.c that the "=" in a lambda assignment no longer performs
eager evaluation.  Instead, it treats it as a plain symbolic definition.  That
is lazy evaluation, which has many advantages in terms of semantic clarity.

The typical drawbacks of lazy evaluation are avoided, because when a value is
evaluated on demand, it is almost always *replaced* with its final value so the
work doesn't have to be done again.  The only exception is when the value has
side effects which must be repeated every time -- and that decision is made by
the type-specific reduction function.

Our new technique allows the elimination of the clumsy "later" concept.  We can
also avoid any concern with forcing eager evaluation for "efficiency" reasons.
We can express functions as simply as possible, and the efficiency comes for
free.

You'll note that to support full inline replacement, I had to introduce an
extra level of indirection in atoms.  That way, we can replace a value like
(. "x" "y") with its final value "xy", without any need to copy atom data.