mtx: Avoid nested panics on lock class mismatch assertions

[jhb]

Summary

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 clas. 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.

[jhb]

I ran into this in CheriBSD where a lock was filled with 0xdeadc0de due to a type confusion bug and the value of the lo_name pointer was filled with 0xdeadc0de. Possibly we could keep the assertion as-is but avoiding printing the lock name at all, just print the pointer? OTOH, we don't require matching classes for other locks. I also think the main point of these assertions is to catch cross-threading in the API, so having them narrower but give a meaningful panic string is probably useful (and why I've chosen to fix it this way). (I've long wanted to make a separate struct spinlock or some such and have mtx only be MTX_DEF and then all these assertions would go away as they would become compile errors.)

[kib]

Note the 'clas' (single s) in the last word of the first sentence of the summary.