Generics: First attempt. Some stuff works, other stuff is fragile.

What works:
function myappend[A](list[A] lst, A value => list[A]) {
    lst.append(value)
    return lst
}

The interpreter is able to call this function with [1] and 1 or [1.1] and 2.2
and it works just fine. However, there's various things that don't work with
generics:

The interpreter is able to handle generic function parameters, but it can't
handle vars or temporaries inside of a function that use generics.

Generics always start with A and go up in sequentially alphabetically. This
may be changed to allow names for generics in the future. I sort of doubt it
thought: I like the consistency of forcing A, B, C...

Some hacks were done in symtab to keep scan_seed_sig from damaging template
parameters (part of the problem there is that scan_seed_sig can be removed
after generics are stable, but until then it needs to be bandaged).

The symtab fools the parser by switching the sig of the template class when
the parser asks for a generic class by name. It's rather nifty, I think.
Drop exception_test.ly now that exceptions seem more stable.

...Or maybe it's that I'm not paying attention to them as much. This should
have been removed a while ago, actually.
Generics: Generic variables now require an initializing assignment.

Consider this:

function f[A]() { A value }

Without this, the vm cannot determine what the type of 'value' should actually
map to. Also, I'd like to eventually have the language require a value during
a declaration (along with Option[A] to remove null-ness).
Generics: Local vars and storages are now resolved in generic functions.

This is a really, really big chunk of getting generics working. Before this,
only the parameters of a generic function would get the proper types. The
local vars and storages of a generic function would be left as-is (and likely
crash/behave strangely).

function f[A](list[A] lst) { tuple[list[A], list[A]] t = <[lst, lst]> }

will now work. If called with a list[integer], then t will be
tuple[list[integer], list[integer]].

With this done, the rest of generics is getting different parts of emitter to
stop doing sig==sig (and template matching), and adjusting the generics
available when a function enters/exits.
Generics: Fix template resolution in eval, call returns, oops in vm resolve.

The first one was that calls were checking only for template_pos of a sig
being non-zero instead of that OR the template class (because A is a template
sig with a template pos of 0.

The second was an issue where call returning was grabbing the wrong signature.
It wrongly assumed that it could just pull from the call signature instead of
properly using the emitter's sig stack.

The final issue was not updating the register count after doing a generic
function resolution.
Simplify eval_call just a little bit.