If a fatal kernel trap occurs from an IPI or FAST interrupt on a cpu not

If a fatal kernel trap occurs from an IPI or FAST interrupt on a cpu not
holding the MP lock, the trap code will panic a second time when get_mplock()
attempts to block due to an assertion in lwkt_switch().  Add a new globaldata
field, gd_trap_nesting_level, that allows us to bypass this panic.

If lwkt_switch() is called with a non-zero gd_intr_nesting_level or non-zero
gd_trap_nesting_level, the two variables must be saved and then zero'd
across the switch, and restored on resume.  Otherwise a normal switch in
another thread will result in another panic.  This case only occurs during
fatal traps, panics, or when operating from DDB.

From-kernel-dumps-provided-by: David Rhodus <sdrhodus@gmail.com>