futex: Add another early deadlock detection check

Dave Jones trinity syscall fuzzer exposed an issue in the
deadlock
detection code of rtmutex.

That underlying issue has been
fixed with a patch to the rtmutex code,
but the futex code must not call
into rtmutex in that case because
    - it can detect that issue early

- it avoids a different and more complex fixup for backing out

If the
user space variable got manipulated to 0x80000000 which means
no lock
holder, but the waiters bit set and an active pi_state in the
kernel is
found we can figure out the recursive locking issue by
looking at the
pi_state owner. If that is the current task, then we
can safely return
-EDEADLK.

The check should have been added in commit 59fa62451 (futex:
Handle
futex_pi OWNER_DIED take over correctly) already, but I did not
see
the above issue caused by user space manipulation back
then.

Change-Id: I245f77622443435cf36bbd157b98798c235acdb0

idea is
taken here -
https://github.com/rmbq/android_kernel_htc_msm8960/commit/d6532e749838fc4dc63c2049dfa4bebdec872ad5