Stacks seem incorrect with offwaketime on Android

`offwaketime` is giving me some weird waker/sleep stacks on Android/ARM64.

Here's one of the stacks it found:
```
waker: find 0
el0_svc_naked
sys_newfstatat
vfs_fstatat
vfs_getattr_nosec
kernfs_iop_getattr
mutex_unlock
__mutex_unlock_slowpath
-- --
try_to_wake_up
kthread_queue_work
sugov_irq_work
irq_work_run_list
irq_work_run
handle_IPI
gic_handle_irq
el1_irq
_raw_spin_unlock_irqrestore
__wake_up_sync_key
pipe_write
new_sync_write
vfs_write
sys_write
el0_svc_naked
target: ActivityManager 1163
69
```
Basically the test was running `find /data | cksum` is running in the background with `offwaketime -K`.

What I see above is 3 unrelated stacks. ActivityManager isn't really involved in the find/cksum activity, yet its identified as a sleeper. Lets assume it did do a pipe_write but further down in the sleeper stack, it doesn't show schedule or any such call that can cause a sleep. All it shows is `try_to_wake_up` which is actually a wakeup function not a sleep function.

Also the `try_to_wake_up` is coming from an interrupt stack, and its a path that is handling an IPI related to cpufreq. This IRQ stack isn't related to the pipe write or `vfs_fsstatat` at above. Its just pure IPI/cpufreq stuff.

Could it be that the IRQ stack (for the IPI) is messing up the offwaketime logic?

@brendangregg , how are we handling IRQ stacks with offwaketime? Like what happens if an IRQ wakes up a task while some other totally unrelated task is running? Is there a false waker/wakee link established there somehow? Any other ideas on the above stack? Thanks!

Start with the offwaketime tool and its -K stack-handling path, then reproduce the report with find /data | cksum on Android/ARM64. Trace how IRQ and IPI stacks are associated with wakeup events, using the shown ActivityManager and try_to_wake_up stacks as the reference. Done means unrelated IRQ activity no longer produces a false waker/wakee relationship.

Written by the indexing model from the issue text.