Enhance memleak to show allocation stacks when trace all is enabled

I have a native executable that now consumes more RSS on startup than it did in a previous version. I'm trying to figure out where the extra memory consumption is coming from. I first had a go at using `stackcount` with `c:malloc` but that didn't show any big differences.

In a second step, I decided to jump into `memleak` and see if it could tell me where all the allocations and frees were happening. I've been able to get this information like this:

```
sudo /usr/share/bcc/tools/memleak -c runner -O /lib64/libc.so.6 -t
...
Attaching to pid 11747, Ctrl+C to quit.
(b'gnal Dispatcher', 11646, 23, b'd..21', 17566.725943, b'alloc entered, size = 16')
(b'gnal Dispatcher', 11646, 23, b'd..21', 17566.725961, b'alloc exited, size = 16, result = 3faff60')
(b'gnal Dispatcher', 11646, 23, b'd..21', 17566.725965, b'alloc entered, size = 8392704')
...
```

Although the information is useful and could be processed to see the differences, the allocation stacks of these threads are missing. I was wondering if it would be feasible to extend these trace messages so that the stacks for the allocations would be shown? Or is there some way to do that already?

Start with the memleak entry point and its existing -t trace output, then compare how stackcount handles allocation stacks. Done means trace-all output includes the allocation stacks for the reported allocations without losing the existing allocation and free details.

Written by the indexing model from the issue text.