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

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 https://github.com/oxidecomputer/opte/pull/761#discussion_r2124930291

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.

Start by locating TokenLock::lock, cv_wait_sig, and their ioctl and attach/detach callers. Trace how signal wakeups are handled, then verify that ioctl callers return EINTR to userland while non-ioctl callers retain their intended locking behavior.