libbpf-tools/deadlock: Support for potential deadlock detection in kernel mode

Could you please let me know what do you think about supporting potential deadlock detection in kernel mode?
User and kernel mode can be selected with options like memleak.py.

As of now, I have a version that traces the kernel's mutex_lock/mutex_unlock.

This is usage example.
The logic of the test kernel module is the same as the deadlock.py test program on the page below.
(https://github.com/iovisor/bcc/blob/master/tools/deadlock_example.txt)

Any comments are welcome.
Thank you.

```
# ./deadlock
Tracing... Hit Ctrl-C to end.
----------------
Potential Deadlock Detected!

Cycle in lock order graph: Mutex M0 (global_mutex3 0xffffffc008f543c0) => Mutex M1 (global_mutex1 0xffffffc008f543e0) => Mutex M2 (global_mutex2 0xffffffc008f54400) => Mutex M0 (global_mutex3 0xffffffc008f543c0)

Mutex M1 (global_mutex1 0xffffffc008f543e0) acquired here while holding Mutex M0 (global_mutex3 0xffffffc008f543c0) in Thread 631927 (lockinvers._t3):
0xffffffc010acc1c8 mutex_lock+0x0
0xffffffc010110100 kthread+0x118
0xffffffc010087078 ret_from_fork+0x10

Mutex M0 (global_mutex3 0xffffffc008f543c0) previously acquired by the same Thread 631927 (lockinvers._t3) here:
0xffffffc010acc1c8 mutex_lock+0x0
0xffffffc010110100 kthread+0x118
0xffffffc010087078 ret_from_fork+0x10

Mutex M2 (global_mutex2 0xffffffc008f54400) acquired here while holding Mutex M1 (global_mutex1 0xffffffc008f543e0) in Thread 631925 (lockinvers._t1):
0xffffffc010acc1c8 mutex_lock+0x0
0xffffffc010110100 kthread+0x118
0xffffffc010087078 ret_from_fork+0x10

Mutex M1 (global_mutex1 0xffffffc008f543e0) previously acquired by the same Thread 631925 (lockinvers._t1) here:
0xffffffc010acc1c8 mutex_lock+0x0
0xffffffc010110100 kthread+0x118
0xffffffc010087078 ret_from_fork+0x10

Mutex M0 (global_mutex3 0xffffffc008f543c0) acquired here while holding Mutex M2 (global_mutex2 0xffffffc008f54400) in Thread 631926 (lockinvers._t2):
0xffffffc010acc1c8 mutex_lock+0x0
0xffffffc010110100 kthread+0x118
0xffffffc010087078 ret_from_fork+0x10

Mutex M2 (global_mutex2 0xffffffc008f54400) previously acquired by the same Thread 631926 (lockinvers._t2) here:
0xffffffc010acc1c8 mutex_lock+0x0
0xffffffc010110100 kthread+0x118
0xffffffc010087078 ret_from_fork+0x10
```

Start with tools/deadlock.py and tools/deadlock_example.txt to understand the existing deadlock behavior and test scenario. Compare that with the requested kernel-mode tracing of mutex_lock and mutex_unlock; the issue does not identify implementation files, tests, or acceptance criteria, so the kernel-mode design and validation plan need to be established first.

Written by the indexing model from the issue text.