Including exports. Not sure what happened.

I realized we need to be doing the state checking in some of
the other ipc functions (perhaps indirectly, e.g. thc_ipc_call).
And then it seemed to make more sense to create a
new data type - a thc channel that wraps a fipc channel with
extras that we need when doing async stuff. So, we still do
ref counting, but it's on the thc_channel.

I no longer free the thc_channel when the ref drops. Leave up
to the libasync user to decide.

I updated the interface so that e.g. thc_ipc_recv now takes
a struct thc_channel instead.

Motivation: thc is cooperative, but there are still cases where
we can get into trouble. In thc_poll_recv, it's possible that
the awe we switch to (to receive a response) wants to kill the
channel that we just polled on. In the original implementation,
after we scheduled that awe, we would eventually come back into
thc_poll_recv, go to the top of the loop, and try to receive
again; but instead, we should just abort (and in fact, we would
be using memory after it had been freed).

When a channel group item is created (with thc_channel_group_item_init),
its state = LIVE, and its ref count is 1. So, the creating awe
automatically gets a reference. When another awe wants to grab
a reference, it should call thc_channel_group_item_inc_ref; and
to release a reference, thc_channel_group_item_dec_ref. dec ref
will remove the channel group item from its group and free it
when the ref count reaches 0. To signal to other awe's (thc async
threads) that a channel is dead, you should call
thc_channel_group_item_mark_dead.

Inits list head, etc.

This is when the libasync user knows there will never be a response
for a particular request, and they would like to free up the
cookie.

Motivation: In some cases, we need to split the sending of the
request from the receipt of the response. For example, in LCDs,
we need to send an async request, then do a *microkernel sync
send*, and then get the async response.

This is now fulfilled by thc_ipc_reply. Tests updated.

Not tested yet.

Looks like we were both headed in the same direction ...

We don't want to have to hold on to the request message until
we reply. Instead, the libasync user passes in a "request cookie",
that is just the message id. The libasync user obtains the
cookie via thc_get_request_cookie.

Not tested yet.

Added tests for timing thread creation. Only tests lazy thread creation for now. Refactored older test code as well.

Disabled preemption and local IRQs. Discovered another stack bug in the Barrefish code where thc_done does not adequately clean up the used stacks resulting in memory leaks.

Finish context switch benchmark test. Still need to disable NMIs and preemption to decrease variance in results.

Need way to change kbuild CC and modify kbuild cflags.

We will use this to mark symbols as weak, so they can be redefined
easily.

Rather than do -fno-ipa-sra and -fno-ipa-cp (no interprocedural
analysis that removes unused arguments, constant propagation, etc.),
we can just turn it off on the function (thc_nested_async) that we
really care about. In this way also, libasync users don't need to
worry about setting these compiler flags.