dont use a semaphore (which doesnt block interrupts in the critical section) to protect the completion ring. mpii_poll can be in the middle of the critical section when an interrupt is generated, but because something is already in the critical section the isr cant clear the condition causing the interrupt and you spin forever entering the isr and being forced to exit it without doing any work by the semaphore.
dont use a semaphore (which doesnt block interrupts in the critical
section) to protect the completion ring. mpii_poll can be in the
middle of the critical section when an interrupt is generated, but
because something is already in the critical section the isr cant
clear the condition causing the interrupt and you spin forever
entering the isr and being forced to exit it without doing any work
by the semaphore.

this moves to protecting the completion ring with a vanilla mutex.
work taken off the ring is stuck on local lists in the isr to be
completed outside the mutex in case a completion path issues a
polled command which will try to call the isr which tries to
mutex_enter while the previous call on the stack would be holding
the mutex...

this diff is large because of the list changes needed to support
the local lists in mpii_intr.

issue found by bluhm@ and debugged by Christian Ehrhardt

orumin/openbsd-efivars,orumin/openbsd-efivars,orumin/openbsd-efivars,orumin/openbsd-efivars