alternate stacks for signal handlers

[Matthew Fluet]

> Well that is certainly disappointing.  Could you add something to the C
> signal handler so that we could see if it is making it into the signal handler?
> I.e., just
> 	{
> 		static char	msg[] = "Signal handler entered\n";
> 
> 		write(2, msg, sizeof(msg) - 1);
> 	}
> Actually, the best thing would be to print out the stack pointer at that
> stage and make sure that it really is switching to the new stack.

I think I finally figured the thread/signals stuff out.  Turned out to be
two additional bugs.  One was a problem with register allocation, which
I'm surprised wasn't flushed out by something else.  It was related to
having a long basic block after a C-call and ending up with one memory
location being cached by more than one register.  The second bug was in
the way I was implementing Thread_switchTo.  I haven't coded up the
"inline" version that appears in the current version of machine.h;
instead, I've been doing an invokeRuntime of GC_switchToThread.  Contrary
to the comment in machine.h, this method isn't entirely correct.  After
some playing around, I figured out that the crucial difference is that
GC_switchToThread did not perform the atomicEnd operation s->canHandle--.  
So, everything got screwed up because the GC always thought it was already
handling a thread operation.

Just for kicks, I tried turning off the alternate signal stack handler to
see what happens.  Stuff still seems to work, but then again, the only
example program I've got to check signal handling is the signals.sml file.
I think that makes sense, since the child thread is spending most of it's
time in a sleeping -- which gets turned into a C-call, so when it receives
the signal, it can use the C-stack that got set up for the call.  But, I
if I turn the sleep into a busy loop (i.e., no C-call), then I get 
erroneous behavior.  So, the alternate signal stack is important.