Made the Tupfile build with libgcc

This fixes the compiler errors I've been having. I'm probably going to
come back to this (again), but for now it seems to build things as I
expect.
Pulled num_to_digits into another file

It doesn't really belong in tty.c, so I moved it.
Fixed a bug in num_to_chars

Before it looped forever, now it doesn't (I think, pending tests).
Incidentally, this change is what prompted me to revisit setup. It
wasn't compiling because dividing a 64 bit integer on i386 requires
libgcc (it's missing __umoddi3 and __udivi3).
Added string.h. No definitions yet

This is needed for some libgcc functionality. More pressingly, I'd also
like to use memcmp for testing num_to_chars and this seems like a good
time to add all of these functions.
Incidentally, I find it interesting that the mem* functions are found in
string.h. It would have struck me that since they don't operate on
null-terminated strings (what I typically refer to when I mention
strings in C), they ought to appear in a mem.h or something like that.
Chalk it up as another design quirk of C, I guess. While I don't think
that C has any horrible design decisions, given its age, I do think it's
rather quirky and that it would be nice if a less quirky language had
come about to fill C's niche (C++ is not less quirky than C).
Preliminary implementation of memcmp

string.h, part 1/4
Untested as of now
Added implementation of memcpy

Still untested. It's interesting that memcpy returns dest. I think I
agree with the stylistic suggestion that functions that mutate their
arguments should not output anything (except an error code or something
like that, perhaps). These functions are mandated by libgcc, so it's not
under my control in this case.
I also find it interesting, if unsurprising, that memcpy makes the
caller enforce non-overlapping regions.
Made memcpy support overlapping regions

This is unnecessary given memcpy's interface, but it seems reasonable to
not make things gratuitously unsafe. My next step will probably be to
pull out the common code into memmove and make memcpy be basically an
alias of memmove.
I'm curious if the memcpys of various libcs adopt my approach, or if
they behave incorrectly when the two regions overlap. I'm hard pressed
to imagine that the extra speed afforded by saving the comparison is
worth it, but I've been surprised before.
Added memmove

As I stated before, I just changed the method name then made memcpy call
memmove. GCC and clang should both be able to inline memmove into
memcpy, but I'd like it to be more explicit that memcpy should really
just be the same body of code with a slightly different interface.
Something to look up on another day, I guess.
Added memset

It's odd that memset takes in an int when it actually fills a region of
memory with bytes.