Lexer: Fix debugging stuff accidently left by previous commit. Oops.
tk_eof is now a val_or_end token. This makes lily_cliexec work again.

If tk_eof is caught by lily_fs, then lily_fs will remark about an unexpected
eof being hit within lily_parser. However, lily_fs is set to a different file
type, and so an eof is fine there.
lily_impl_send_html -> lily_impl_puts

Not all runners send html, so the old name didn't reflect what it really did.
The new name does: It's the interpreter's way of doing a 'puts'. It currently
is only used by the print function and html though.
Upgrade msgbuf so that lily_impl_debugf can be blasted. Touchup debug.

I did some touchups to debug's show_value, which it seems wasn't updated
properly since values started containing sig and flags. So I simplified that
a bit.

Added lily_msgbuf_add_fmt which accepts a format string and args. This has now
replaced all uses of lily_impl_debugf, which no longer needs to be wrapped by
runners. This also simplifies debug a bit, since most of the format strings
take the place of 2+ lines of code.

Also added lily_msgbuf_add_sig. Signature adding is now unified within msgbuf,
another nice thing to come out of this. No more syncing two versions of that.

lily_impl_debugf is now gone, and all runners (except apache) now have a
working lily_impl_puts implementation (at least one had it as a stub)).

This change was done because I couldn't find an apache function that would
print data from a va_list. By having the msgbuf do what lily_impl_debugf once
did, that's no longer important: There's just one easily wrapped
lily_impl_puts, which is easily handled by apr_puts or somesuch.
The interpreter now takes runner data in a void *.

lily_impl_puts now takes a void * as the first argument. This is the same data
that runners pass as the new first argument to lily_new_parse_state. This is
passed around to lexer and vm (with vm handing it to debug). The interpreter
does not touch this pointer at all: It's strictly for the runner.

This was done so that the apache module can obtain the request_rec without
having to resort to global variables or other evilness.
Success! The apache module is able to successfully parse a file!