Split the stack walking behavior out of `minidump-processor`

[Alex Franchuk]

The new minidump-analyzer binary relies on minidump-processor for stack walking. However, this brings along a lot of extra dependencies which are unused (e.g. yaxpeax). Normally this might be a situation where a feature would be appropriate, however in combination with a need to audit dependencies with cargo-vet, it would make things much simpler to have stack walking as a separate crate.

Besides stack walking functionality, minidump-analyzer also needs the new debug info symbol provider from minidump-processor. That will need to go into a potentially new split-out crate, or there could be another crate with symbol providers. It is annoying that cargo-vet can't support features so it forces us to break functionality into little pieces, though ultimately there isn't that much overhead aside from e.g. coordinating future additions that need to change multiple crates. The vendoring/auditing team felt much more comfortable with splitting the crates up (if possible) rather than adding a bunch of exemptions for the enormous crates which we aren't actually using. Not to mention vendoring those large crates would be cumbersome, too (or at the very least hacky with some dummy/stubbed out/patched versions).

@Gankra I'm wondering if you have any thoughts on this?