Add support for zerocopy

[lynlevenick]

I’ve opened a PR for this because I got a bit ahead of myself, but it would be nice to support zerocopy in addition to bytemuck. They implement largely the same API surface, though zerocopy has traits that are a bit more fine-grained. It doesn’t look like zerocopy fully supports portable SIMD, though maybe I’ve just done it wrong.

[bitshifter]

Hi there, because it's a bit of a burden maintaining support for new optional features, especially if they use some kind of derive macro and can't be self contained in `src/features, I was wondering what your motivation is for using zerocopy over bytemuck. I'm not opposed to adding zerocopy support, I'd just like to better understand motivations and needs to people in the community with respect to adding new optional dependencies.

[lynlevenick]

For me the major difference is that bytemuck’s API has its unconditional casts annotated with possible panics on errors, while zerocopy does not - I believe it’s able to enforce more invariants at compile time, by being more restrictive on the input types to unconditional casts. For example, compare zerocopy::transmute_ref! to bytemuck::cast_ref. zerocopy supports an explicit Unalign trait and struct that can support alignment differences, but it doesn’t expose that potential runtime error. While I could be more careful and never write a bytemuck cast that would result in a panic, I could instead use zerocopy and never be able to write a panic at all.

edit: the must cast feature on bytemuck appears to support similar behavior, so maybe that’s sufficient for my needs after all

[lynlevenick]

I’ve got some time tonight so I’m going to try to clean up the PR, particularly removing the ByteEq/ByteHash stuff since that is divorced enough from what I’m doing here that I think if it needs to be in here I’ll try to make a separate issue for it.

edit: I've done the above.