Lexer no longer uses hit_eof to calculate line bumps.

If an eof has been seen, the reading functions now check if the eof is at the
start of a line or not. If it isn't the start of a line (meaning that code
terminates with an eof instead of a newline), then bump the line number as if
it were a newline. Otherwise, don't bump the line number.

The lexer's hit_eof was causing problems with loading/unloading files since
a loaded file will always have an eof at the end. This would causes the
original file to never increment the line number for the last line if the eof
was not at the end.

Cutting away hit_eof is just a bonus.
FINALLY!!! Internal code by text, not ids. Fixes #68.

Since the beginning of Lily, internal functions have been scooped up by using
ID parsing. It is...was pretty awful. To define print, something like this
was used.

{SYM_CLASS_FUNCTION, 0, 1, {-1, SYM_CLASS_STRING}}

The symtab reads this as:
* This is a function.
* It doesn't have varargs (the 0).
* There is one argument.
* -1 means there is no return.
* SYM_CLASS_STRING is the type of the return.

There were a some minor problems with this:
* It's verbose
* It's easy to get it wrong
* The scanning code was a pain.

But the big problem was:

By scanning functions in through IDs, it is completely impossible to have a
set of C-based modules that the interpreter can use. No module could guarantee
that the ids it uses would not be used by another module. Want namespaced
stuff? Nope. How about stuff from the user? Also no. This meant that a mysql
type of module would be unable to, say, use some regexps.

In this new system, code can now be written as it would be in Lily, except
that the functions don't take names for their parameters (the names would be
discarded anyway. This may change.) The print function is now

"function print(string)"

All internal functions now use text to define things instead of ids. This has
allowed the removal of some pretty awful code as a bonus. The only thing that
still uses the old way is the exception class (because there's no inheritance
just yet!)

This also paves the way for the interpreter defining some core stuff within
itself through text. In the future, I may make it so the higher-level kind of
classes (the exception-based ones) are defined through code sent to the
interpreter by itself to simplify the symtab's current job. Additionally, this
will make importing easier in the future, because a few file push/pop bugs
were solved in doing this.