`TokenLock` should bubble up `EINTR` to userland callers when awoken by a signal

[FelixMcFelix]

I think we probably want two different versions of TokenLock::lock() - one which is sensitive to signals (for use in ioctls, etc), and one which is not (for use in attach/detach). The signal-sensitive locking function (lock_sig()?) could then return an error if cv.wait_sig() indicated reception of a signal, allowing the ioctl to emit EAGAIN, rather than potentially going into a furious loop around the cv.wait_sig() call if a signal is pending.

Originally posted by @pfmooney in #761 (comment)

cv_wait_sig (and friends) will call into issig_forreal() and handle a SIGSTOP, which is the crux of how we have gotten past #758. However, any other signal could cause threads awaiting the TokenLock to enter a very hot busy loop (and potentially become stuck) until the resource is released.

We need to have callers who attempt to take this lock in an ioctl context exit early and return EINTR up to userland, which will then be responsible for retrying the request.