Kernel stack get/put interface

Also cleans up the poison/canary, and if you need to, you should be able
to get larger stacks (change the KSTKSHIFT).
Kthreads track running kernel contexts

Previously, we would only create a kthread on-demand to hold a kernel
context when it wants to block.  Now, we always have a kthread tracking
the running context.
Kthreads track cur_sysc and cur_errbuf

Instead of having them sit in pcpui, then copying them to the kthread,
we just put them directly in the kthread.  This matches their intent.
Using pcpui was more of a hack back when we didn't have kthreads at all
times.

Note that set_errno() can be called before we have a kthread set up,
hence the need to check for its existence.
Kthreads launched from KMSGs are tracked as ktasks

The kernel tasks don't have a particular address space, and won't store a
reference to whatever process happens to be running.  Previously, things like
loopbackread() would save a reference to whatever process happened to be
running there, which would keep that process from fully DYING.

Any routine kernel message will have is_ktask set.  If they block, the kthread
code will know to handle these differently.  This means that syscall context
shouldn't somehow try to execute as an RKM.  As a reminder, when you first
launch an RKM, it is in early_rkm_ctx.  So put another way, no syscall work or
other work on behalf of a process that can block should execute in
early_rkm_ctx().  Anyway, this all is subject to change, if I need to.
Comments inline will track the latest.