Merge o_build_list and o_build_tuple into one opcode.

While writing o_new_instance for classes, I realized that these two could be
merged by making the initialization loop use rhs->sig since that will always
be the proper thing: For lists, it'll never change, for tuples it'll always be
what that particular index should be.

Hurray for a simpler vm!
Register info no longer holds class info. Show properly dumps funcs now.

I don't think the former has really been working for a while. I'm pretty sure
it would have stopped working when functions got their own table in the vm's
function table. Anyway, even if it DID work, there's a better way to get the
class name of a function given.

The better way is to print the class info of a particular function when within
'show_function' of lily_debug. This has access to functions called directly,
and can print class info on them. I've tested this with list::append to make
sure it works.

This also saves a little memory, as functions no longer have a spot in
register info for holding class information.
Implement 'calltrace(=>list[tuple[string, integer]])'. Fixes #52.

I decided to put this alongside show, because why not? Additionally, the bug
mentions that the result should be a list of 'tuple[string, string, integer]'
(two strings). The reason that this wasn't done is because there is no import
(and thus no filename to print). I'll update calltrace when import works.

This is a handy function for determining the current Lily call stack. This
could later be used for debugging (ex: A function that shows the call stack
before calling a class function to determine what is calling that class
function).

Note: Built-in functions have the integer part as -1, which I might fix to 0
later. Lily is different in that it adds foreign function entries to the call
stack. I may also make it where calltrace doesn't add itself to the trace
later too.