Structure VarZeroSlice as an "enum"

[Manishearth]

https://github.com/unicode-org/icu4x/issues/5378 is adding VarZeroLengthlessSlice. However, it cannot be used inside VarZeroSlice because VarZeroSlice has an optimization where empty slices are represented as the empty array, so we cannot do

struct VarZeroSlice<T, F> {
   length: RawBytesULE<4>,
   indices_and_data: VarZeroLengthlessSlice<T, F>,
}

However, @sffc had an idea. We could write a very simple abstraction that wraps [u8] which produces an Option<&NonemptyVarZeroSlice>, and NonemptyVarZeroSlice is represented as above. This is a simple optimization.

I'm not considering this a part of #5378 but I think it should be on the cards for the future! It's purely internal.

[sffc]

You know I like generalizing things, and of course I see an opportunity here :)

It seems like this could be struct ZeroEmpty<V>([u8]) which is an "enum" (not a literal Rust enum) between None and a V when nonempty.

I can't currently think of any other users of this abstraction than VarZeroSlice, but it seems like an easy building block to write, at least internally, with well-defined safety invariants that should be easy to pass unsafe reviews.

Actually I guess this would be VarZeroOption? That seems like a good type to export.

[Manishearth]

Hmm, yeah, potentially? I'd start with an internal abstraction first, but yes, it would be cool to incubate this and see if it fits in the overall zerovec œuvre.

The main problem with making this publicly usable is that this would require an additional unsafe trait that asserts that the type never has DST size zero. Otherwise VarZeroOption<str> would become None for empty strings. Which, might actually be possible to do safely, as a "This is an Option and if you give it a type that can have len 0, the len 0 case will be None". The nice thing about VarULE types is that they don't have destructors or other ownership semantics, so having a Some "turn into" a None is ... probably fine?? As long as we document it?

Anyway, tricky design questions for making it public.

(So, in favor of this abstraction, as usual somewhat wary about making it public, but it feels like a good path to have it be an internal thing that we iterate on and incubate)