This matches the precise conditional we use elsewhere; we can end up
trying to grab the console for a panic that isn't routed through kdb
with, e.g., an explicit call to panic() via a failed assertion or some
such. The scheduler's generally stopped by the time we try to do a
window switch, so we shouldn't try to do any of the normal locking.
Note that this doesn't mean we'll succeed at grabbing the console. If
i915kms is active, for instance, then we won't be able to switch to
ttyv0 to draw the panic message. This does avoid stacking an additional
unrelated panic on top of a panic that we're actually interested in,
though.