This will not work unless you implement thc_dump_stack_0 and
thc_link_to_frame_0 for your architecture. Moreover, the implementation
of thc_dump_stack_0 should continue walking the stack until it
hits either a null frame or return address. (The usual way is to
assume stacks are aligned at certain addresses and to stop the walking
when you reach that alignment. That WILL NOT work here.)

Phew ... Lots of debugging. This is the commit in which I
discovered AC/THC fails when it uses %rsp offsets instead of
%rbp offsets. And that we need to be careful with local variables
inside ASYNCs.

Anyway, this commit does the following:

    -- You can build for LAZY/EAGER using a configure flag:

            --enable-eager

       By default, it builds for lazy.

    -- Fix abort example to yield async 0. The print out result
       is quite interesting.

    -- Fix caller to use alloca, just to be paranoid about passing
       the local variable transaction_id. This is probably not
       necessary in this example, but it demonstrates the care
       required to pass locals in async's.

See THCAbort, THCStopAllAwes, THCShouldStop. Like kthread_stop
in the Linux kernel, stopping is voluntary.

Add abort example.

Not built or tested yet.

    -- thc_ipc_send ==> thc_ipc_send_request
    -- thc_ipc_recv ==> thc_ipc_recv_response
    -- thc_ipc_recv_response ignores requests and messages that
       are neither requests or responses (i.e., it only handles
       responses). See updated header documentation.
    -- awe_mapper_create_id and awe_mapper_get_id no longer
       BUG on error conditions; they return a non-zero exit status
       instead.
    -- THCYieldToId and THCYieldToIdAndSave return non-zero if
       the id does not match an awe.

Not built or tested yet. Updated examples. (In the context switch
example, I just BUG on in there, so you have the same semantics
as before.)

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.