consider using/copying backtrace-ext to more properly filter the backtrace

human-panic currently skips a hardcoded number of frames which is... not what you want to do:

https://github.com/rust-cli/human-panic/blob/c0e52f47213eebfb3212f8029ff5705fd0e0c091/src/report.rs#L47-L52
https://github.com/rust-cli/human-panic/blob/c0e52f47213eebfb3212f8029ff5705fd0e0c091/src/report.rs#L66-L71

Rust emits two magic frame names to delimit the "runtime glue" from the "real stack". Unfortunately the backtrace crate doesn't support handling that for you. As such I made backtrace-ext::short_frames_strict to do that for everyone who is implementing this kind of logic.

The example is basically already human-panic's impl because I found this problem in miette which copied your impl. I can do the PR for you but I wasn't sure if you were ok with adding this dep (it's basically one complicated function but slightly factored out so I could unit test the crap out of it because you should never trust backtraces to provide decent input).

(NB: at the time of filing this issue I've published 0.2.0 but docs.rs is super backlogged. 0.2.0 includes fixes from me adding all the comprehensive tests, and also removes the "re-export of all of Backtrace" because I realized it's goody. If you see this issue soon enough just know that this line in the example changed to import Backtrace from backtrace and not backtrace-ext.)
(0.2.0 is live now, also I cut 0.2.1 to lower the msrv)

Start in src/report.rs at the two hardcoded frame-skipping sections linked in the issue, then compare their behavior with backtrace_ext::short_frames_strict. Check the dependency and MSRV implications described in the issue; done means replacing the brittle filtering with the proposed behavior and verifying that the panic report still shows the intended stack.