Classes: Functions defined inside the ::new of a class now linked into it.

Previously, this:

class Point(integer x, integer y) { function f() { } }

would not result in 'f' being made available only within the Point class. Now,
f is pulled into the functions provided by Point. However, there are things
about it that don't work (A class instance is not the first value, for
example).

It's a step in the right direction though. :)
Classes: Functions have implicit self and class names for trace.

A function defined within a class is now assumed to have self as the first
var. This is currently not accessible (the name is not a valid var name), but
that's so that self can be reached via @ in the future.

Additionally, native function vars are now created with a class name if there
is a class name. Now, exceptions that are raised inside of a class function
will print the class name and their own name, making it clear that they're
part of a class.

I've also made it so that blocks now contain 'self'. The intent is to use this
to make nested classes possible (because if nested functions are possible,
then nested classes should be as well).
Classes: Property creation, get, and set working. Fragile!

class Point(integer xx, integer yy) { integer @x = xx, @y = yy }

Now, the interpreter creates @x as property 'x' within the Point class.
Within the constructor to Point, the property x is only available as @x. This
is done so it's obvious that a property of a class is being used and not some
global or local variable somewhere. The idea is borrowed from Ruby.

Outside of the class, @x is accessible through instances of Point using the
'<value>.x' notation. The interpreter also checks that a class doesn't make
multiple properties of the same name. Additionally, the interpreter requires
a value when creating a new property.

This is not an accident. In the future, I intend to have all assignments
require a value, (but only after an Option class and a None value have been
provided).

Classes are still fragile, but at least they're getting better.
Classes: Values passed to the constructor are no longer properties.

I actually don't care for this too much. So remove it, making it where only
properties declared -within- the constructor become properties. I ended up not
liking automatically making things properties, because now every property has
to have a @ prefix to be used.

Also, user-defined class properties are now linked from first to last (with
the properties of a class holding the start). A class now holds a prop_count,
the number of properties it has instead of a start (the start wasn't used
anyway).
Classes: Fix an oops that broke 'integer @x = 10, @y = 11'.

Just a small oops within declaration parsing. No big deal. I also moved the
helper for parse_decl with other shared functions to keep things neat. Decl
parsing was touched up just a tiny bit to do checks against token instead of
lex->token so much.
Classes: Calls to member functions automatically get self.

This was fairly simple to do: A function call already adds the function as the
first argument (and then later picks it off). This simply checks if the tree
holding the function should get 'self' instead (and count it as an argument).

This does a basic test to prevent calls to global functions from getting self.
This test will need to be improved when user-defined classes can nest as well
as inherit from each other. Consider:

Class A() {
    function f() {   }
    class B() inherits A {
        f() # This should work, since B inherits A and A defines f.
    }
}

Hurray for classes starting to be less fragile!
Parser: Function capture now recurses to capture. Fun! Fixes #57.

So I had a fun bug in classes:

'''
class Point() { function f() {} function g() { f() } }
Point p = Point::new()
p.g() # Error: Got 1 arg, expected 0.
'''

Huh? Both f and g are defined within a class, and should both get an implicit
'self'. Inspecting further showed that...

class Point entered...
    function f processed
class Point exited...
    function g processed

The problem is that function collection was simply continuing over the same
loop. When function f exited, the } that closed it was yielded up to the
caller. This is why Point thought it was closed when it wasn't.

Because of this, recursion is now used for handling function collection. I've
also tested the same example in lily_cliexec before committing this to make
sure this works (also, the implicit self passing seems okay too).

With this, I consider user-defined classes to be stable enough to push to
origin and close #57.