GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing

This is something that can be seen in crashes from stack watermark processing:

in report_fatal
    detail_fmt=0x7f2e101e92f8 "acquiring lock %s/%d out of order with lock %s/%d -- possible deadlock")
 in Mutex::set_owner_implementation
 in Mutex::set_owner
 in Mutex::lock_without_safepoint_check
 in MutexLocker::MutexLocker
 in GCLogPrecious::print_on_error
 in VMError::report
 in VMError::report_and_die
 in report_vm_error
 in ZVerifyBadOopClosure::do_oop
 in JNIHandleBlock::oops_do
 in Thread::oops_do_no_frames
 in JavaThread::oops_do_no_frames
 in ZVerify::verify_thread_head_bad
 in ZStackWatermark::start_processing_impl