Inspired by Ashen-Shugar,
Crack-code by Ryan D. AKA Sketch


This is an almost completely different way of handling all markup,
special characters, and all the text handling that goes on inside Penn.




Instead of constantly changing the form of ANSI strings in order to pass them
to and out of functions, I propose we hold EVERYTHING in parallel arrays for
its entire parsing. Most (if not all) of the markup is composed primarily of
on/off states, so this is easily done and very fast, but... 

How do we keep from eating memory? It's actually rather simple. There are two
criteria that must be met for any memory to be allocated for any given markup
type: it must be consequential, and it must be used.

What this means is, in this example string, we'll never allocate memory for
ANSI:
think add(ansi(hr,1),2)

Because add() wouldn't use the ANSI anyway.

However, some side-effect functions like setq() and pemit() will require us
to unset the flag that disallows markup allocation, since they do not
necessarily return their arguments, but store/emit them to other places.

So with this structure of allocation, an obvious problem could be something
like this:

think ansi(hr,ansi(hr,ansi(hr,ansi(hr,...

and so on. However! We don't allocate memory for markup *until it is needed*.
Due to the fact that Penn's parser moves in-to-out, this code will only have
2 ANSI-markup buffers allocated at any time--the one being acted on, and the
one the ANSI() is returning its string to. 

In such a way, the memory usage will typically never grow large. The greatest
number of allocated strings for any given markup seems to be:

function_recursion_limit + (max number of function arguments)

This brings up the problem that some functions can have MAX_INT arguments,
so a way to deal with such will be constructed--it's likely to be very simple.