With this commit, we track the ast that built up each shadow value, and
then at each operation track the most specific AST that is general
enough to be a rooted subtree of all the shadow values that passed
through it (where x in the generalized tree can stand for any subtree of
the shadow values). Haven't added this to the output format yet, but if
you use the --print-expr-updates arg, you'll see a message every time an
op gets hit, which prints its updated AST.

This way, the op ast is initialized when we add it to the tracker, which
might be important.

Now properly handles the debug info getting functions returning false.

Specifically, leaf AST's were being initialized on the creation of every
shadow location, and then immediately overwritten with branch AST's when
they were used for the result of an operation. Now, we don't initialize
them at all on creation, and rely on the sites of creation to know what
they'll be used for, and initialize them properly.

Don't share AST pointers between shadow values, just copy them, and then
clean them up when the values are cleaned up due to the reference
counting system.

Debug info is enabled on the executable. I'm looking for a more robust
way to do this.

This is the only ternary function I could think of, so this is useful
for testing argument stuff.

Now it uses a variable number of args to assign child values, instead of
asking the client to do it manually.

I mean, I haven't seen any bugs yet, but I haven't actually started
implementing the printer for the named vars, so I wouldn't.

This is an op info for the leaves of a computation. Pretty important for
tracking variables in an expression, but so far there's no way of
associating sources of shadow values with a consistent leaf op info, I'm
brainstorming ways to do this.

Each opinfo keeps track of potential value sources for it's
arguments. Value sources are place where values are created, leaves of
the tracked operation AST's. This happens when we start interpreting
some bytes as a float value for the first time.

Adds support for having all operations/expressions show up in the output
file, by setting the error threshold to zero.

Instead of rolling our own like we did before, this seems less error prone.

We don't technically need to call any mpfr code, but it'd be a hassle to
remove it since it would involve creating a seperate compile process.

This really should have been here all along, lets us rebuild the
binaries for a full run of the results

This way we get both versions of quadratic instead of having them
overwrite each other during compilation in weird ways.

Instead of removing items from the op tracker when they are
subexpressions, we've gone back to just setting them to NULL. This is a
little ugly, but it avoids the horrors of trying to iterate backwards
through a list while removing cosmetically arbitrary items from it.

Only when the print_moves flag is on