lang: Add function values and lambdas

This adds a giant missing piece of the language: proper function values!
It is lovely to now understand why early programming language designers
didn't implement these, but a joy to now reap the benefits of them. In
adding these, many other changes had to be made to get them to "fit"
correctly. This improved the code and fixed a number of bugs.
Unfortunately this touched many areas of the code, and since I was
learning how to do all of this for the first time, I've squashed most of
my work into a single commit. Some more information:

* This adds over 70 new tests to verify the new functionality.

* Functions, global variables, and classes can all be implemented
natively in mcl and built into core packages.

* A new compiler step called "Ordering" was added. It is called by the
SetScope step, and determines statement ordering and shadowing
precedence formally. It helped remove at least one bug and provided the
additional analysis required to properly capture variables when
implementing function generators and closures.

* The type unification code was improved to handle the new cases.

* Light copying of Node's allowed our function graphs to be more optimal
and share common vertices and edges. For example, if two different
closures capture a variable $x, they'll both use the same copy when
running the function, since the compiler can prove if they're identical.

* Some areas still need improvements, but this is ready for mainstream
testing and use!

lang/interfaces/unification.go

@@ -36,4 +36,13 @@ type Invariant interface {
 	// Matches returns whether an invariant matches the existing solution.
 	// If it is inconsistent, then it errors.
 	Matches(solved map[Expr]*types.Type) (bool, error)
+
+	// Possible returns an error if it is certain that it is NOT possible to
+	// get a solution with this invariant and the set of partials. In
+	// certain cases, it might not be able to determine that it's not
+	// possible, while simultaneously not being able to guarantee a possible
+	// solution either. In this situation, it should return nil, since this
+	// is used as a filtering mechanism, and the nil result of possible is
+	// preferred over eliminating a tricky, but possible one.
+	Possible(partials []Invariant) error
 }