Emitter: Upon entering a function, mark the sig stack.

So...it turns out there was this function in emitter called
lily_update_call_generics that was supposed to be called upon function entry
to ensure that the emitter's signature stack would be ready for the number of
generics available.

It turns out that not only was that function incorrectly written, but it was
also not being called. In fact, looking at the history, it was NEVER called.
So...whoops.

Anyway, the proper action is to allow declared functions to share a common
bottom of the emitter's signature stack (with a generic adjust set so that
calls don't damage that information).

Additionally, these generics are assigned the generics themselves. In a recent
commit, I realized that this is the proper thing to do, because within a
generic function, the generic vars are quasi-known (that is, each A, B, C,
etc. is known to be some common type). So assigning something with generic
information to a concrete type (say, integer) is incorrect because it cannot
be known if that is correct.

Additionally, a test has been added that makes sure that an empty list can
default when the left side contains a generic. Before this patch, the emitter
would do an invalid read and then complain about 'list[A] cannot be assigned
to list[any]'.
Emitter: Function block exit should not touch emitter's sig stack.

All declared functions share a common set of generic signatures resolved to
themselves at the bottom of the signature stack. There is no reason to do
this (and it may even be dangerous).
Lexer: Only teardown the first entry when exiting.

This...caused a bug that I spent a considerable amount of time trying to chase
down.

The problem is that because of parser's forward token, it might run into a
situation where the first file has eof and the lexer goes to enter a file too.
Recall that builtin commands are read as fake files.

If this isn't done, then the test that was patched with this will say that
the filename is <str> (because the string holding string::concat for the
interpreter to bootstrap thinks there is no active file).
Calls can now infer their result by their parent, sometimes.

Consider this:
    class Container[A]() { ... }
    Container[integer] c = Container::new()

Before this patch, the interpreter would say that Container::new() should
default to any for A because A is unknown.

However, a smarter way to do things is to use the value wanted (the left of
the assign, Container[integer]) to infer what result would work.

With this patch, the interpreter builds Container[integer] and the assignment
works just fine.