Prototype use of zerocopy crate in zerovec

[sffc]

Some of the operations in the zerovec crate, especially those involving ULE, could be modeled with abstractions in the zerocopy crate. Parts of the zerocopy crate are being proposed to the standard library in Safe Transmute. It would be good to see how much unsafe code could be eliminated in zerovec by adding zerocopy as a dependency, so that we can influence the Safe Transmute RFC and prepare longer-term for zerovec sitting on top of those operations.

The biggest catch is that zerocopy doesn't currently support fallible conversions, which is quite fundamental to how ULE works. This could be partly resolved by a private infallible conversion function invoked from a custom public fallible function, but zerocopy also does not currently support private conversion functions. @joshlf said in an email:

The problem is that there's no way, using zerocopy, to enable a transmute only for a single module - if your type is public and the transmute is possible, it's possible for everyone. I'd think that you could support your use case by defining a private type, defining your public type as a repr(transparent) wrapper around the private type with extra invariants, doing a transmute using zerocopy operations on the private type, and then doing a single unsafe step at the end to convert to your public type (thanks to repr(transparent), the safety argument should be very simple).

We'd also like const conversions; we have them in some places, but not everywhere. I would love to see a generalized const conversion API so that we can make a proper zeroslice! macro as proposed in #1935.

CC @joshlf @ezrosent