Implement various soundness fixes

[LegionMammal978]

Rust's aliasing model disallows creating exclusive &mut references from shared & references, except through an UnsafeCell. Therefore, I modified Desync and UnsafeJob to no longer do that. (Note that *mut pointers are the fundamental type for shared mutable access.) Also, the Box in Desync can't exist alongside the &mut references created in the jobs, so I made action store the pointer resulting from Box::into_raw(); the drop() function similarly calls Box::from_raw(). Finally, since Desync is an interior mutability type with no poisoning, I used a PhantomData to mark it as !RefUnwindSafe, since it can leak data across a catch_unwind boundary with a shared reference.

This is a breaking change. It fixes #6.

[LegionMammal978]

Actually, there's more soundness bugs with the signatures of the future_[de]sync() methods. To illustrate:

use desync::Desync;
use futures::executor;

fn leak_local<T: Send>(v: T) -> &'static mut T {
    let desync = Desync::new(v);
    let future = desync.future_sync(|v| async { v });
    executor::block_on(future).unwrap()
}

[Logicalshift]

👍 Thanks for these changes: this improves the crate a lot, I think. The examples you have provided are very helpful for me in understanding the issue.

I'm going to merge these changes, then move them over to the 0.9 branch as they do change the API.

I no longer remember why I forced the type to be Unpin: I suspect it was to do with an earlier implementation of the futures algorithm. It does indeed seem to not be strictly required any more.

The futures issue looks like a problem introduced when I shifted away from forcing the future functions to return a boxed future, where the lifetime was restricted using a higher order trait bound. I've got a fix for this (I think), so I've opened a new issue (#8) to track the problem.