Avoid taking deadlock_graph_mu when locking a Mutex with no other locks held

In debug builds with deadlock detection enabled, locking a Mutex takes the
global deadlock_graph_mu spinlock to look up the Mutex's graph id. This also
gives a graph node to every Mutex that is ever locked. But graph ids are used
only to add lock-order edges, and there are edges to add only when a thread
acquires a lock while it holds another.

This change looks up graph ids only in that case. A held lock gets its id when
the thread first acquires another lock while holding it. As a result:

- lock(), lock_shared() and LockWhen() take deadlock_graph_mu only if the
  thread holds another lock, and try_lock() and try_lock_shared() never do.
- Mutexes that never take part in nested locking no longer get graph nodes.

This does not change behavior. DeadlockCheck() already looks up a held lock's
id again if it is no longer current, and only acquisitions made while holding
another lock use the ids.

DeadlockCheck() looks up the held locks' ids before the acquired Mutex's id.
GraphCycles ranks each new slot above all existing nodes, so if a held lock and
the acquired Mutex both get new slots, the edge between them is already in rank
order.

PiperOrigin-RevId: 1003192716