Fixes x86 FPU initialization

Need to clear the FPU header state before saving the default copy.  My
guess is the PXE agent / bootloader used FP and left us with a full,
dirty FP stack.  Though perhaps the CPU just decided to start like that.
Either way, that bad state was bleeding through to the SCPs / thread0s,
which increase the likelihood of errors in apps (CFL errors in
fluidanimate, which can also cause page faults).
Fixes race with vcore_yield()

In some scenarios, the kernel would think we wanted <= 0 cores
(negatives triggered the > max_vcores() check), if we were yielding
repeatedly while messages arrived.
Adds helper program to sleep / block

$ usleep MICROSEC
Fixes bug with ksched running while an SCP dies

The local SCP could be dying (via an exit(), for example), but before
the __death KMSG is sent, and IRQ triggers the ksched tick KMSG, which
will happen before __death.

Notice we can't send a __ksched_tick message, since that would rearm the
(probably) already armed alarm, using the same awaiter.  This would
result in a few problems, one of which was runaway __ksched_tick kmsgs
that exhaust the system's memory...

This is a little clunky, in that the ksched needs to deal with this.  An
alternative would be to make launching an SCP (proc_run_s()) operate
with RKMs, or make SCP death *not* use RKMs.
Checks addr + len after adjusting addr in mmap()

When setting addr to BRK_END for anonymous mappings, we could have an
addr + len that passes UMAPTOP.
Removes redundant event handler, exposes others

The old handler wasn't being used - was overwritten by uthread code.
The main difference is that the uthread handler knows how to deal with
the CAN_RCV_MSG flag.

This also exposes the uthread's preemption/indir handlers, so that
applications can wrap the handlers with their own handlers.
Changes formatting on prov and pthread_test
Adds helper program for reading max_vcores

This is used by shell scripts to get max_vcores.  We don't have pipes
working yet, so the answer is passed via the return value.  You can do
something like:

maxvcores
MAXVC=$?
pthread_test $MAXVC 9999999999999999 $MAXVC &

to launch pthread test so that it will run forever and want all of the
cores available.
Defines ACCESS_ONCE(x) macro (XCC)

This forces a one-time read of the value x.   I've been meaning to do
this for a while - we have a lot of synchronization code that assumes
that data is only loaded once, at a specific point in time.  Eventually
I'll go through older code and start using this.

Check out http://lwn.net/Articles/508991/ for more info.

This will also help with code that wants to force a read-in (say, from
global state to thread state) for performance reasons.

Keep in mind that we continue to need memory barriers, like the wmb(),
wrmb(), etc, since this has nothing to do with the processor's ordering
of operations, and also has nothing to do with writing values.

This is fairly similar to a cmb(), in that both tell the compiler that
memory values may have changed.  One slight difference is that a cmb()
(and rmb/wmb on x86) involves an asm volatile, which should prevent the
compiler from reordering the accesses (I think!).  AFAIK, the compiler
could reorder:

local_x = ACCESS_ONCE(x);
local_y = ACCESS_ONCE(y);

and if it is important to actually read x before y, then you want to do:

local_x = ACCESS_ONCE(x);
rmb(); /* on x86, this is just an asm volatile("" ::: "memory") */
local_y = ACCESS_ONCE(y);

The rmb() orders the x and y reads, and the ACCESS_ONCE prevents the
compiler from trying to read in x in the future when using local_x.

Finally, note that any use of an rwmb() (where we want to enforce the
read happens before the write) will probably want to use an ACCESS_ONCE,
unless we are okay with reading the value again after the write.

Reinstall your kernel header.
Fixes race in SCP yielding (again) (XCC)

979bce86 had the right idea, just the wrong code.  Took a while to
actually have this happen (usleep 1 wasn't sufficient, even in a loop.
Had to have a few other things going on).
Allow WAITING->RUNNING_S transition

Used by the proc_yield SCP path.  In this case, we're not involving the
ksched in the fake wakeup process.  Also note that the MCP yield code
doesn't need this, since it doesn't synchronize based on the process's
state (it uses the vcore's state).
Allow the killing of WAITING processes

Children are not inherited or killed or anything.  They get a parent ==
0, which is like processes launched from the monitor.
Removes any restrictions on process control

Until we have a real solution, the half-assed "direct parent only" (or
self) control test doesn't really do much.
sys_poke_ksched() on behalf of other processes

So something like 'prov' can kick the ksched to make it notice the
changes faster.  It's not a huge deal, since provisions are a
fine-grained choice, but it also doesn't hurt.  And it helps with some
testing code.

No need to rebuild the cross compiler, but you do need to rebuild any
MCP app and all of parlib.
prov pokes the ksched after a successful provision

The ksched will eventually notice, and since provisioning is rare, it
shouldn't matter either way.  However, this is useful for test programs.

This also cleans up the retval work a little.
Speeds up regular MCS locks

Even when the qnode is allocated on the stack (perhaps especially then),
CL aligning it reduces cache-line contention (false sharing of the CL
with the main thread using its stack).

Also this exposes some lower-level MCS locking functions.
MCS-PDR locks cache vcoreids

We read-in the vcoreid of whoever we may need to spin on before
signalling.  This both cuts down on cache contention (less re-reading of
the pred's qnode to get the vcoreid) and gets rid of the restriction of
having qnode memory be safely accessed, even after unlocking.  Both
changes help with performance.
MCS-PDR locks take a *qnode

Futex code can use either spinpdr or mcspdr, up to them.  For the
semaphore code, it was a simpler change to just change the lock style.
RISCV uses CAS-style MCS-PDR locks
Adds ndelay() to parlib