Add support for function calls

We can now parse argument lists of any length and there is a way of defining
built-in regular functions. This required a special case in the evaluator for
zero-arg functions.
Add tests to make sure parsing works fine for aggregates
Get rid of accidental line that was used for debugging
First pass at compilation for aggregates

-Implement a few simple aggregate functions in the runtime.
-Detect if a Select expression is an aggregate by checking if there is at last
one aggregate function used in any select fields.
-Represent aggregate functions with a different AST type, since they'll need to
be called differently.
Change functions to always take and return lists

New plan for dealing with nested aggregates: aggregates are just regular
functions, and every function maps from list to list. The main thing to handle
with aggregates now is to change the context when evaluating the innermost
aggregate (and non-innermost aggregates are evaluated like regular, although
awkward, functions from a single row to a single row). This approach is also
nice because it lets us selectively transition operations to use numpy in the
future if we need to.
Add compilation for aggregate functions

If there's any aggregate in any of the select expressions, we give a special
type context for aggregates that only gets access to the table columns inside of
an innermost aggregate. We also only output a AggregateFunctionCall for
innermost aggregates rather than every aggregate.
Add evaluation for basic aggregates

Evaluation contexts can now have aggregate contexts that we switch to when
entering an aggregate function. Since I'm not supporting actual GROUP BY yet,
this is easy: if we have any aggregates, we evaluate with an empty context that
has the real data as an aggregate context.