Uthread code no longer tracks detailed states

Uthread code only cares about RUNNING vs NOT_RUNNING, and this is only
to catch bugs.  The 2LS is responsible for any state it wishes to track,
such as the diff btw blocking on a syscall, joining, exiting, blocking
on a mutex, whatever.
Pthread code calls uthread_runnable() consistently

We were doing a mix of calling the schedop directly and indirectly
(uth_runnable).  This is a little slower, but all paths involving waking
up a uthread go through the same code now.  External code (e.g. mutex
libraries) will use uthread_runnable().
Pthread state tracking

We don't do anything smart in pth_thread_runnable(), but that's where
you can make different decisions on what to do with the thread based on
why it slept/woke up.

All yielding/blocking paths will touch the 2LS (pthread in this case),
and that is where the 2LS can record info (states) for later
(thread_runnable).
2LS thread_blockon now takes the uthread*

Keeps it in line with the other 2LS thread ops.  Need to do some void*
trickery for upcoming patches, and because C is picky about void* vs
struct xme* as parameters in function pointers.
uthread_yield() takes a func* and arg

We had a variety of ways to pass info across the uth_yield->__uth_yield
boundary.  Instead of doing all of that, we just tell uthread_yield to
run a function when it gets to vcore context.

The purpose of this function is to somehow deal with the uthread and its
reason for blocking.  This could be because it blocked on a syscall, or
perhaps for some 'external' reason, such as blocking on a mutex.  This
setup allows the mutex code to not be aware of 2LS-particulars, though
it still needs to know about uthreads.  This will help us with mutexes
and libraries that aren't bound to a particular 2LS, as well as simplify
many different mechanisms (like the pth specific stuff for join/exit).
Pthread join/exit/yield use the uth_yield func ptr

Instead of passing info via states and flags, we pass info via the
function pointer, like all other uses of uthread_yield.  This allows us
to clean up join/exit/yield a bit.

Now, all yield paths touch the 2LS, and in those callbacks the 2LS sets
the pthread's state, which it then sees in pth_thread_runnable() later
on.

Fun note: there was a cryptic comment above pthread_exit():

/* This function cannot be migrated to a different vcore by the
userspace scheduler.  Will need to sort that shit out. */

I think that was talking about the old version of exit, back when there
was no uthread library and when exit and yield had separate (but highly
similar) functions for getting into vcore context.

If you're curious, check it out.  It was from a commit 2 years and a day
ago.  (f35c3ed435fd).
Tracks state properly for paused uthreads

Pthreads uses a state for threads stopped from below (currently only for
preemptions (either pending or recoverery)).

Uthreads just tracks them as NOT_RUNNABLE.

This patch also provides a helper for the three usages of
copyout/sched_ops->paused.  Depending on what 2LSs need, we might
provide copyout directly again, but for now we'll leave it as an
internal helper.
proc_destroy() now starts in the ksched

This allows the kernel scheduler to lock first, which helps with some
other lock-ordering trickery we do, and allows the ksched to do
additional cleanup, other than just receiving the idle cores.

Additionally, we have less of a need for put_idle_cores() (the only
caller is an old preemption function, which might get sucked into the
ksched soon).
Fixes TAILQ usage in arsc.c
Kernel scheduler tracks procs 'cradle to grave'

Previously, the ksched would only know about processes whenever it
needed to make a decisions.  For MCPs, this was always.  For SCPs, it
was only when runnable.  Now it knows about them from register_proc()
(called during proc creation) until proc_destroy(), which recently
became a ksched function (this was part of the motivation for that).

This also allows the ksched to not need to poll the queues to detect if
someone is dying or not.  That messiness is gone, and the ksched just
gets called for proc_destroy().
Proc refcnt no longer needs '+1 for existing'

This reference is managed by the kernel scheduler.
proc_change_to_m() is now a scheduler function

Due to issues of lock ordering.  We need to atomically change process
state and tell the ksched about it.  The way to do this without
deadlocking is to grab the ksched lock first.  Ultimately, we're going
to end up tying proc and ksched code together a bit, where proc code
does the bidding of sched code.
proc_wakeup() - spammable and starts in the ksched

Need to have the ksched lock held while waking up so that we atomically
wake up and alert the ksched (via the callbacks).  If we grab the ksched
lock after the proc lock, we can deadlock.  If we unlock the proc lock
before telling the ksched, we could have another core try a
proc_destroy(), and the ksched would destroy it after the old
__proc_wakeup, but before the ksched finds out about the wakeup.  So we
enter the call via the ksched, and grab its lock first, like with
destroy().

Note that excessive spamming of proc_wakeup would hurt the ksched a bit
(coarser lock than all the proc locks), but all cases expect it to be a
necessary call.  For instance, the event code all peaks at the state of
p, making sure it was WAITING before bothering the ksched.  We'd have
excessive calls only if two or more cores tried that at the same time
and all saw WAITING before the ksched called __proc_wakeup to change it
to RUNNABLE.
proc_wakeup() replaces schedule_scp()

All places wanting to make sure a proc runs now can spam proc_wakeup().
This commit makes new-proc calls and yield-related calls that aren't
already in the ksched call proc_wakeup().

This should also have cleaned up the last of the deadlockable lock
orderings (ever since we had proc_destroy in the ksched, it was possible
to deadlock during a concurrent sched_scp()).

Finally, this just gets rid of schedule_scp(), which was in no way
related to the __schedule_scp().  Ugh.
Wants top of stack, not bottom...
big speedups for memcpy/memset
risc-v boot process bugfixes
risc-v supervisor mode updates
on risc-v, initialize core_stacktops; fix halt

halt needs ints enabled!
on risc-v, emulate keyboard input using an alarm