Add support for Enum types

[dorny]

Enum type can be decomposed into its variant index (uint) and rest of the data whatever they are.
Fixes #21

[dorny]

I wrote some additional notes in #21 (here).

Two element array might work well.
I'm not sure about extended type. We would need to know size of serialized enums ahead of time.
I'm out of ideas how this would be possible to implement without significant overhead.

Is my approach different from how structs are encoded/decoded?
I saw there is map_length emitted althought it's not used in reading and field names are not emitted too.
Are structs written as arrays? Are struct compatibile with spec and other implementations?
Oh wait, Msgpack doesn't have struct in spec either...

Maybe another option would be to have separate project implementing something similar to Msgpack but specially designed for Rust and performance. Thanks to Rust it should be very easy to switch between different serialization formats. I have some plans with implementing rust actor library and framework for distributed computing on top of it. In this case and similar ones, enum support and performance is critical.

[mneumann]

Yeah, I think extended types would require us to buffer the data, which I don't want for efficiency reasons. Structs could be also implemented via maps, but we don't do this for efficieny and space overhead. It's a pity that msgpack doesn't define this more properly.

You are completely right, reordering of field in structs have the same effect as reordering enum constructors. So, I am fine with just a two element array :).

As long as other msgpack implemenations can read what we emit, I am fine with it. Inter-language compatibility is a myth... not even the two versions of the msgpack spec are really compatible (treatment of binary vs. string).

[mneumann]

@dorny: So if you come up with a patch for 2-element array, I'll commit!