How about another try at enum classes?

So...it turns out that I had some misconceptions about how enum classes and
variants should work. There's no functionality change, though things seem less
likely to crash this time.

Enum classes now create classes instead of needing classes. Additionally,
there is no need to use ::new to create instances of a variant. This means
that usage of enum classes and variants is simpler. In going with the Option
class example, it's now possible to use Some(x) instead of SomeType::new(x).
More importantly, 'None' can be used in place of NoneType::new().

Unfortunately, variants kind of break some previous Lily things. For one,
trying to 'show' a variant that takes args (even though it looks like a
function) will not show function code since a function is not used to create
variant values.

Variants cannot be used with the wrong number of args either (so the use of
None() would be invalid). I don't like the non-showability of variants, but
not enough to roll this back.

Variant-related tests updated too.

Warning: Variant-related code is still fragile. Be careful.
Massive change! Variables now demand an initializing assignment.

Now that enum classes have landed, it's now possible to use an Option with
Some and None to represent variables which may or may not be initialized.

Because of this, Lily now DEMANDS that ALL variables have an initializing
assignment. I do not expect this to change, since I have been really wanting
this for a long time now.

All tests have been updated to initialize variables on assignment. The emitter
now disables a variable being used to initialize itself too. I deleted one
test because it involved nil-ness (which is a now-dying concept in the
interpreter).
Only primitive values can be condition cases now.

Previously, a condition using an 'any' would work. It doesn't now. Conditions
must be either an integer, a double, a string, or a list.

Lists are considered truthy based on a count of elements. Strings are
considered truthy based on their size. For that case, the literal optimization
was fixed to reflect that (previously, an empty string was truthy).

o_jump_if no longer checks for nil-ity or to unbox 'any' values. This is
another step toward erasing nil-ity.
The assumption that user vars can be nil is gone.

This assumption has been baked into the code from the very beginning. Combined
with the other changes today, it marks a massive change in how Lily works
that has been ingrained in Lily since it was made.

Intermediate values can still be nil (and this is the reason that there is
still a fair amount of nil-checking code that will never die). However, the
user should never see any values that are nil.

With this commit, I wave goodbye to user-level nil-ity.