Capture execution backtrace when throwing UnexpectedCycle

[Veykril]

cc #856

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	7dc685c
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/68380c8bf34cfa00083f1174

[Veykril]

Note with this if you have a cycle to debug in a test @ChayimFriedman2 you can at least wrap your test temporarily in a UnexpectedCycle::catch the stuff

[codspeed-hq]

CodSpeed Performance Report

Merging #883 will not alter performance

_{Comparing Veykril:veykril/push-tsptqqtnuxwk (7dc685c) with master (f9a9bb2)}

Summary

✅ 12 untouched benchmarks

[MichaReiser]

I should probably have raised this on the original PR but what's the motivation for raising a more specific value over a regular panic considering that this isn't something a program can easily recover from (unlike a cancellation which is a valid exit state). I guess, what I don't understand is what are the situation where we want to catch this (without triggering a panic hook)

[carljm]

what I don't understand is what are the situation where we want to catch this (without triggering a panic hook)

cc @nikomatsakis as creator of #704

We are hitting this in ty, also -- there's currently no way to get backtraces from a cycle panic, which is a problem. We either need to revert #856 or land this PR. Similar to @MichaReiser, I don't really understand the rationale for #856, so I would be inclined to revert it, but I think ty could also adapt if this PR were landed.

[carljm]

This looks good to me, and I think is necessary if we don't revert #856.

[carljm]

I'm going to go ahead and merge this; I think it's strictly an improvement over the status quo. We can still separately discuss possibly going back to simple panic.