Introduce RefUnwindSafe StorageHandle

[Veykril]

David noticed in rust-lang/rust-analyzer#18964 that Storage isn't unwind safe (on a related note it also obviously isn't sync due to the local state). So this is a proposed design at solving this by introducing a non-local state handle (which hence disallows running computations on it). This would allow you to have a non-local state handle, move that across unwind boundaries, threads, etc and once you need todo computations you can turn it into a handle with local state.

In rust-analyzer I would imagine us holding such a non-local state handle in the main global state and whenever we dispatch a request, clone it, move the clone off to the dispatching thread and then materialize it as a local-state hanlde (Storage).

We could directly implement UnwindSafe on Storage (note how we used to implement RefUnwindSafe already, which is the wrong trait at this stage of the setup), given that if we have no references outstanding the query stack will be empty anyways and so we wouldn't run into issues with moving it across an unwind boundary. That doesn't sit quite right with me though so instead I've opted for this setup, as it also feels like a natural extension to the API to me. A side effect of this is that the non-local handle is Sync, though that is likely not too useful as there is no reason to wrap it inside (interior) mutability.

I've added respective RefUnwindSafe implementations where required to make the auto trait impls work as expected with comments explaining the rationale as to why they ought to be correct.

cc @davidbarsky

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	4e44751
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67ab2ccc81871d0008a5beb2

[codspeed-hq]

CodSpeed Performance Report

Merging #675 will not alter performance

_{Comparing Veykril:veykril/push-xsrukmlqwrlm (4e44751) with master (351d9cf)}

Summary

✅ 9 untouched benchmarks