runtime: clean up panic and deadlock lock ranks

I'm not entirely sure why these locks are currently ranked "deadlock <
panic" since we drop panic before acquiring deadlock, and we actually
want deadlock to be below panic because panic is implicitly below
everything else and we want deadlock to be, too. My best guess is that
we had this edge because we intentionally acquire deadlock twice to
deadlock, and that causes the lock rank checking to panic on the
second acquire.

Fix this in a more sensible way by capturing that deadlock can be
acquired in a self-cycle and flipping the rank to "panic < deadlock"
to express that deadlock needs to be under all other locks, just like
panic.

For #53789.

Change-Id: I8809e5d102ce473bd3ace0ba07bf2200ef60263f
Reviewed-on: https://go-review.googlesource.com/c/go/+/418719
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>

src/runtime/mklockrank.go

@@ -169,8 +169,10 @@ stackLarge,
 mheap, mheapSpecial < globalAlloc;
 
 # panic is handled specially. It is implicitly below all other locks.
-NONE < deadlock;
-deadlock < panic;
+NONE < panic;
+# deadlock is not acquired while holding panic, but it also needs to be
+# below all other locks.
+panic < deadlock;
 `
 
 // cyclicRanks lists lock ranks that allow multiple locks of the same
@@ -185,6 +187,8 @@ var cyclicRanks = map[string]bool{
 	// Multiple hchanLeafs are acquired in hchan.sortkey() order in
 	// syncadjustsudogs().
 	"hchanLeaf": true,
+	// The point of the deadlock lock is to deadlock.
+	"deadlock": true,
 }
 
 func main() {