Attempts to fix uth_disable_notif()

There were two problems with disabling notifs.  First, using the uthread's TLS
is a bad idea.  The uthread might not have it, and then it's using the vcore's
TLS.  That alone might be okay, since the uthread pins itself to the vcore
(we'd have to do the check after disabling migrations and other shit).

The bigger issue is with locks grabbed in uth context and unlocked in vcore
context.  When we reenable, we would not reenable notifs, nor even adjust the
depth counter.  Vcore context just blows past those checks.  Likewise, uthread
code will never unlock it, since the unlock calls typically happen in the
uthread_yield() callbacks.  We could try and have the vcore code figure out who
was locking and adjust the depth, but that's just a pain in the ass (and
doesn't work well with locks help by both vcore context and uth code (e.g. the
pthread runqueue lock)).

This commit changes three things: uses the uthread struct for the depth, has
vcore code reset the depth during yield, and does some cleanup/debugging.

The rule for uthread code that grabs locks (or otherwise disables notifs) is
that vcore context will reset the disabled depth to 0, and uthread code should
not try to reenable notifs past the yield point.  Vcore code will enable notifs
when it relaunches the uthread.  There might be issues with this, where some
uthread disables notifs, makes some call that yields (or blocks on a syscall!)
and then reenables notifs.  Note that PDR locks count as enable/disable sites.

For cleanup, I don't see why there would not be a current_uthread, and put in
an assert to catch things (for now).