mtx: Avoid nested panics on lock class mismatch assertions

It is only (somewhat) safe to dereference lo_name if we know the mutex
has a specific lock class that is incorrect, not if just has "some"
incorrect lock class. In particular, in the case of memory
overwritten with 0xdeadc0de, the lock class won't match either mutex
type. However, trying to dereference lo_name via a 0xdeadc0de pointer
triggers a nested panic building the panicstr which then prevents a
crash dump.

Reviewed by: olce, kib, markj
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D49313

(cherry picked from commit dba45599c498deed01e1c98acef74e183c1bbf8d)