The interpreter can now handle static lists+hashes with variants.

Previously, the interpreter would allow bare variants in static lists and
hashes. This is a problem, because the interpreter doesn't like bare variants
and it isn't consistent with previous behavior.

In the event a static list/(or the values of a static hash) have variants or
enums, the interpreter will call a function to fix them to the same type.

If all variants+enum class values agree on a type, then that becomes the type
of the values.

If it is a collection of variants and generics of the enum class are missing,
then the missing generics are filled with type 'any'. This can happen when,
say, with an Option enum class where a static list contains [None, None, None]
(which would become list[Option[any]] now).

If the variants and enums do not agree on a type, then each variant is put
into an enum based on what information it has alone. Missing generic
information is filled with 'any', as usual. All values are then put into an
'any'.

Additionally, emit_rebox_value now checks if the result is an 'any' and the
input value is a variant. If the input is a variant, the variant is first put
into an enum class value (with missing generics filled in with type 'any')
before being put into an 'any'. This prevents bare variants from being visible
within an 'any' (which is inconsistent with other parts of the interpreter).

Symtab: A bug was fixed in calculating the siglist_size of a 'constructor'
return signature. This was fixed because it was crashing the above code. All
tests show that this did not break anything.

A test has been added to make sure variants are defaulting correctly within
a static list (and a static hash).
Bugfix: `hash[integer, any] h = [1 => 1] failed`.

The problem was embarassingly simple: hash building was checking if hash
values were mixed (and making them into any's if that was the case). However,
it was not checking if the value was expected to be 'any' (and making values
into anys in that case).

Test added, because why not?
Emitter: Oh yeah, tuples and variants.

Tuple building now accounts for variants and enum classes. That was a mistake
from the last commit. Unfortunately, tuples have to jump through an annoying
little hoop of fixing emitter's sig_stack_pos now. The reason is some
functions that tuple build calls want to use the sig stack too. Nothing too
bad though.

Added a test for tuple defaulting too.
Emitter: Return now fixes variants into enum class values. Test added!
Match has landed. This finally closes #67.

This commit introduces support for a match operation that works like a
conditional block (match <expr>: { ... }).

All match blocks must always be multi-line blocks. I decided to do this
because I have made all 'case' conditions within match automatically
multi-line so that there won't be a pollution of { and } between cases in a
match expression.

(Assuming 'enum class Option[A] { Some(A), None }'

What works:
* Decomposition. A 'Some' value will require one identifier since it has one
  value contained with it. Lily, in following with other languages that offer
  this match feature, does not require that types be specified. It does type
  inference for the variables.
* Tests have been added to make sure that match cannot try to decompose a
  variant without a value, and to not decompose something that should be
  decomposed.
* If the match block is incomplete, a message is printed saying that it is,
  as well as what variants have not been cased for.
* Values at the end of each match case scope out. So a 'None' case won't see
  what the Some decomposed to, or any values declared within the Some case.
* Match cases do not have to specify code, and is intentional. My reasoning
  behind this is that a case without code is a way of saying that "I don't
  need to do anything here." However, a missing case is assumed to be a
  mistake in forgetting to add a case after having added another variant to
  an enum.

There is no support for the use of, say, _ to indicate that a decomposition
value should be ignored. I intend to add that at some point in the future.