Preparation for IPL_IPI removal, the bulk changes.
Interrupt changes and IPL_IPI removal.

Removing IPL_IPI was not as simple as intended, mainly because of a
deadlock on fpusave_proc():

cpu0: syscall -> KERNEL_LOCK() -> fpusave_proc(), which sends ipi to
	cpu1 and busywaits for completion.
cpu1: crit_enter() -> KERNEL_LOCK()

Deadlocks since cpu1 will never get the IPI.

This would not happen before since there was no code that spun on
KERNEL_LOCK while at IPL_IPI.

To solve it, I had to advance my plans of running interrupt handlers
with interrupts enabled as well as fixing crit_rundeferred() to run
with interrupts enabled.

This is a bit tricky since ci_ipending must be protected by cli/sti,
but the handler itself must be run with interrupts enabled.

In order to fix this, we also had to recriate the old assumption:

"No kernel lock spining while at IPL_IPI", now critical sections.

Therefore, it is illegal to do:

crit_enter();
KERNEL_LOCK();

mi_switch() now has a code to release all critical sections and
re-acquire them after grabing the big lock, very much like SCHED_LOCK.

This approach is temporary, in the future I'd like to:

Never run interrupts on a critical section, preemption of interrupt
threads will be prevented solely based on fixed priority scheduling,
thus, critical sections will become _very_ rare, and will only be used
to protect the scheduler (blocking clock interrupts), IPIS, and
prevent preemption. This constitutes a different approach than
dragonfly and freebsd which make kernel threads imply critical
sections.

Took me 3 showers to think of all the bugs.