crossbeam known bugs

Affected versions of this crate use orderings which are too weak to support this data structure. It is likely this has caused memory corruption in the wild: <https://github.com/crossbeam-rs/crossbeam/issues/97#issuecomment-412785919>.

Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null). The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.

Even if an element is popped from a queue, crossbeam would run its destructor inside the epoch-based garbage collector. This is a source of double frees. The flaw was corrected by wrapping elements inside queues in a `ManuallyDrop`. Thanks to @c0gent for reporting the issue.

Affected versions of this crate use orderings which are too weak to support this data structure. It is likely this has caused memory corruption in the wild: <https://github.com/crossbeam-rs/crossbeam/issues/97#issuecomment-412785919>.

Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null). The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.

Even if an element is popped from a queue, crossbeam would run its destructor inside the epoch-based garbage collector. This is a source of double frees. The flaw was corrected by wrapping elements inside queues in a ManuallyDrop.