MDEV-37974 Avoid bogus deadlock in lock_rec_insert_check_and_lock()

[arcivanov]

When a transaction holds a granted lock on a record and another
transaction is waiting for that same record, an INSERT by the
lock-holding transaction into the gap before that record would
incorrectly enter lock_wait() on the waiting lock, creating a
false deadlock cycle.

In lock_rec_insert_check_and_lock(), after
lock_rec_other_has_conflicting() returns a conflicting lock,
check whether:

1. the conflicting lock is WAITING,
2. we hold a granted lock on the same record, and
3. no other transaction holds a GRANTED lock that conflicts
   with our INSERT_INTENTION.

Only skip the lock wait when all three conditions are met. The scan
for granted conflicting locks is needed because lock inheritance
during purge can create granted GAP locks from other transactions
that coexist with our LOCK_ORDINARY but still block
INSERT_INTENTION.

The bogus deadlock in lock_delete_updated and versioning.update
(MDEV-14829 section) is also eliminated. In lock_delete_updated,
the DELETE no longer deadlocks but the row at the new PK position
is missed by the forward scan (pre-existing behavior). In
versioning.update, the concurrent UPDATE on a system-versioned
table no longer deadlocks because the historical row INSERT
correctly skips the waiting lock.