Adds an OS-agnostic header for TSC readings

Linux programs can #include tsc-compat.h to get similar calls to Akaros
library calls for reading the tsc and gettings its frequency.

If someone feels inclined, they can write an overhead detector for
Linux, being mindful of IRQs and the ksched.
Pthread barrier work

Pthreads will block on a barrier now, instead of spinning and yielding
(pthread_yield() would keep them on the runqueue).

Not clear yet what is the best spin/block strategy.  !threads_active is
safe, but not always optimal.
Perf debug test

Based on one of fluidanimate's stages.  Runs a little faster on Linux
for some reason.  If the perf of an MCP is significantly worse than an
SCP, then check for SpeedStep / Turbomode.
Defines new struct user_context (XCC)

Changes some #includes to get everyone calling ros/trapframe.h instead
of ros/arch/trapframe.h.
Switches kernel trap.h #include order

All places (other than asm) should include trap.h, not arch/trap.h, such
that the main kernel include is the 'gateway' header to all trap
functionality, just like ros/trapframe.h, atomic.h, etc.

I can see pros and cons of doing it this way vs the older way (arch
first), but I'm leaning towards arch-second unless someone has a really
good reason not to (even knowing that we'll have to be careful where we
 #include the arch file, like in atomic.h).
Uses kernel_ctx instead of TF for kthreading

We're trying to be more explicit about what sort of trapframe we're
using at any given time.

This also gives us a layer of code indirection (it should compile the
same for now) that may be helpful later.
Kernel messages no longer take *tf

I've been considering getting rid of this for a while - it is mostly an
artifact of old-school KMSGs that operated on running TFs, which was
from back before we were tracking the user-tf via pcpui->cur_tf.  Those
old messages wanted to operate on the user context, not whatever
hardware TF happened to be running at the time the KMSG executes.
Changes hardware trapframe calls to use new struct

All places where we used a struct trapframe and that was a HW trapframe
(compared to a SW trapframe or user_context) now use the new struct
hw_trapframe.

I considered removing the TF from the monitor calls, since I don't see
much use in it.  Monitor functions that want to use it can't assume it
is there (only ever called from breakpoint).  Maybe we'll find a
debugging use for it.
Kernel uses user_contexts, instead of TFs

Pcpui changed to use user_contexts.  Changes set_current_tf to ctx
variants.  Proc and other arch-independent code are all converted.

The kernel headers (and therefore userspace) still use TFs, and
arch-dependent code (like init_tf and pop_tf) still use TFs.
Kernel arch-dependent functions use user_contexts

It's up to each arch to determine how they will use the HW and SW TFs in
the user_context, including callee-saved FP state.

Just to help with bugs, I put some asserts in each arch's pop_ctx.
Renames struct trapframe -> hw_trapframe (XCC)

VCPD still uses the HW TFs, instead of contexts.
Procdata uses user_contexts (XCC)

This changes the kernel interface from struct trapframes to struct
user_contexts.  I also found some ancient documentation, though I'm sure
a lot more of it is out of date (esp regarding preemption).

Userspace libraries (and ancient ghetto test programs...) use the new
kernel interface, though the user-level arch-dependent functions still
operate on HW TFs (instead of contexts).

Also, c3po looks like it might not work; not sure what its deal is/was.
Uthread arch-dependent code uses user_contexts

Still use HW contexts in all architectures, but each arch can make the
change to SW contexts (for uthreads and syscalls) at their leisure.