* Use a full-block undos instead of small byte-range undos for
B-Tree nodes.

There is no bug here per-say, but we are trying to improve
HAMMER's ability to recover after a power failure where a disk
drive is writing to the platter at the time of the failure.
While we have no control over any unrelated sectors that might
get smashed by such an event, the concern is that sectors being
specifically written might get corrupted beyond the ability for
the byte-range undo to fix.

The reason is that if, say, only 50 bytes in a B-Tree node need
updating, HAMMER must still do a 16K physical write to disk, so
really any portion of that 16K can wind up corrupt on a power
failure, not just the 50 bytes being changed.

So instead of writing a byte-ranged 50-byte UNDO we now write
a 16K undo for B-Tree elements.

* The hope is that this will improve cases where HAMMER has become
unmountable due to CRC errors in the B-Tree closer to the root of
the B-Tree (which are usually updated to update only the mirror_tid)

This can be helpful in cases where old modules for some reason
had not been cleaned when the location was still /boot/modules
and have ended up getting objcopy'd to /boot/kernel after the
location was changed.

* Record the expected kernel stack pointer along with the pcb_onfault
action. Adjust the trap code to only take the action if the frame's
stack pointer matches the recorded expected stack pointer.

Otherwise this might be a recursive trap and we definitely do NOT want
to execute the on-fault stuff in that situation.

* Prior to these changes recursive traps during uiomove()s could result
in a kernel stack so corrupt that finding the actual cause of the panic
becomes impossible. This is believed to be making life difficult for us
trying to track down a particular i386 panic.

* On x86-64 we had to increase the size of the pcb structure. kgdb on
kernel cores and live kernels will be effected (needs recompile).

* The info structure for the pmap_inval*() API is only initialized
conditionally as an optimization.

* There was a case where the info structure was being used without
first being initialized which matches reported panics (essentially
a pipe buffer page in kernel memory is swapped out and the faulted back
in during a uiomove).