Innodb: Avoid Implicit Lock check when the lock queue is not empty

This potential improvement is found during review discussion of MDEV-34877: Lock priority.

Usually the idea of implicit locking works great as not many modifications is expected to generate conflict. The general idea I had in mind is (I think I have seen in other DBs) that we either have an implicit lock (some modification and no one else is interested) or a queue of explicit locks but not both. So, it intrigued me that this scenario in MDEV-34877 actually shows the presence of both implicit and explicit locks simultaneously. I checked it out and I see we actually could have such case and that is why we check for implicit locks unconditionally while locking a key.

This fix should attempt to enforce the constraint to create explicit lock always when there are other explicit locks already present in the lock queue for the same key. We could then avoid checking for implicit lock unconditionally. It is expected to improve scenarios involving secondary index and high concurrency where the cost of checking implicit lock is high.

We need to also check for possible performance impact while creating new explicit locks.