x86: handling unregistered IRQs

If we receive an IRQ for a vector with no handler, then we don't know
how to send an EOI.  Before this commit, if you sent an I_TESTING, we
would just do nothing.  Since we don't send an EOI, we'd never receive
another interrupt.

In general, we probably shouldn't be receiving interrupts that we don't
have handlers registered for, but who knows.  For testing, at least, I
can imagine receiving more IRQs.

Note the bit about POKE too - those are racy and since poke doesn't go
through the main IRQ handling, it won't deal with the halt race
(abort_halt()).
CPU state tracking

Whenever the CPU transitions between states, we account for the amount
of time spent in the previous state in pcpui.  This will be useful for
accounting.  The downside is that we have a few more rdtsc calls, each
of which costs about 30 TSC ticks/cycles (Core i7-950, I think).

For example, given a process in userspace (state == USER), we take an
interrupt (change to IRQ), then after hard IRQ context, we go into the
kernel (change to KERN), and then eventually pop back to userspace
(change to USER).  Three rdtsc calls.  For a syscall, the transitions
are just USER->KERN, then KERN->USER.

In the future, we can add helpers to disable the rdtsc part, if it turns
into a pain.  I'll look into it more when I speed up syscalls.
RISC-V broadcast IPI

Needs a look, etc.  The RISC-V port needs a bit of work.
mpstat - accounts for time in CPU states

For the pretty version, cat \#K/mpstat.

If you want to read the data with a program, you probably want
mpstat-raw.  All the lines are fixed size, so you should be able to seek
to a particular offset for a particular CPU.

You can reset the values by echoing reset into either mpstat or
mpstat-raw.

Since the CG cores might be sitting idle, they won't update their state
unless they get an IPI.  By default, when you execute mpstat, it'll send
this IPI.  You can turn that off in the ctl message, which is probably
only useful if there is a program that is polling mpstat-raw.

I haven't implemented the for disabling the rdtsc yet.  I'll do that if
it turns out that there is a noticeable overhead, or maybe if it helps
with debugging.