Fix deadlock detection after ForgetDeadlockInfo() on a held Mutex

In debug builds, the Mutex deadlock detector records each lock order edge
(A is held while B is acquired) in a global graph keyed by Mutex address.
ForgetDeadlockInfo() erases everything recorded about one Mutex by removing its
graph node. The header says to call it when the lock ordering of a Mutex
changes. ~Mutex() also calls it in debug builds, so that a new Mutex at a
reused address does not inherit the old one's history.

Each thread keeps a list of the locks it holds, so that it can add an edge from
each of them when it acquires another lock. This list identified a held lock
by the graph id that was looked up when the lock was acquired, and
ForgetDeadlockInfo() makes that id stale. So, before this change, if any thread
called ForgetDeadlockInfo() on a Mutex while some thread held it:

- The hold was ignored for lock ordering until it was released.
- unlock() looked up the entry by a newly assigned id, so it never removed the
  entry. After 40 leaked entries the list was full, and the detector silently
  stopped checking that thread. For example, if a thread held a Mutex 50
  times, and each time another thread forgot it, a later a -> b, b -> a
  inversion on the first thread was not reported.
- AssertNotHeld() compared a new id with the stale one, so it passed although
  the thread held the Mutex.

These effects were accidental. This change identifies held locks by Mutex*
instead. ForgetDeadlockInfo() still removes the Mutex's graph node, and now:

- If the calling thread holds the Mutex, that hold is still ignored for lock
  ordering until it is released. A new per-entry flag marks such holds.
- Holds by other threads keep counting. When such a thread next acquires
  another lock, the detector looks up the Mutex's new graph id and records the
  edge. This includes the later hold of a thread that was blocked in lock(), or
  waiting in CondVar::Wait(), when the Mutex was forgotten.
- unlock() always removes the entry, so the thread keeps being checked.
- ~Mutex() also removes any entry for the Mutex on the calling thread, since a
  Mutex destroyed while locked is never unlocked. Previously, destroying 40
  locked Mutexes on a thread (as in Mutex.LockedMutexDestructionBug) filled the
  list and disabled deadlock detection on that thread for the rest of the
  process.
- AssertNotHeld() fails for any Mutex that the thread holds, even after
  ForgetDeadlockInfo().

These rules do not depend on when a graph id was looked up. This lets a
follow-up change look up graph ids only for nested locking, without changing
behavior.

As a side effect, unlock() and AssertNotHeld() no longer look up a graph id, so
they no longer take deadlock_graph_mu or create graph nodes. (Before, unlock()
even created a new node for a forgotten Mutex.) So a lock()/unlock() pair now
takes deadlock_graph_mu once instead of twice. ~Mutex() still takes it once.

Code that calls ForgetDeadlockInfo() on a Mutex that other threads hold may now
get deadlock reports. First, those holds now count. Second, threads that used
to stop being checked after 40 leaked entries keep being checked, which can
also surface real inversions that involve other Mutexes. This mainly affects
code that calls ForgetDeadlockInfo() right before every lock, to turn off
deadlock detection for one Mutex.

PiperOrigin-RevId: 1002421692