Fix race in lithe_context_block()

There was a race between someone calling lithe_context_block(), it's callbacks
firing, and someone else calling lithe_context_unblock() on the same context.
Independent of the ordering of the callbacks, one or the other would mess
things up because they could both potentially trigger
a lithe_context_unblock() on the blocking context.  If we run the context
callback first (which does the actual blocking from the applications
perspective), then there's a chance that another vcore owned by the
application might unblock the context and start running it before the
scheduler callback executes. If we run the scheduler callback first, then
there's a chance that we unblock the main context and start running it on
a different vcore before we run the context callback.  These races seems
benign on the surface, but it causes weird problems since the callbacks
themselves are arbitrary functions that may rely on running to completion
before the context they are firing on behalf of resumes.  Additionally, since
the arg passed to __lithe_context_block() is stored on the stack, if the
context is allowed to resume before the callbacks complete, these stack
variables disappear and we end up executing garbage when we run (arg->func).

We also now allow a NULL func to be passed to lithe_context_block() if there
is no context callback to execute.
Fix comment
Fix up some semantics in lithe_fork_join_scheduler

Combine mallocs for the scheduler and the main context into a single call, as
well as the contexts and their stacks into a single call. Also fix up the
interface a bit so that it can be extended more easily by other schedulers
(i.e. libgomp-lithe).