Transparent newtype struct representation

[SX91]

#129

Changed encoding of struct A(B) from [B] to B.
This PR is for newtype struct only. Variants and units are harder, so I'd like to discuss it first.

[3Hren]

Thanks! This is a breaking change (however, valid), so I need to test all my dependencies, whether it breaks it and fix them if so.

[coveralls]

Coverage increased (+0.04%) to 87.139% when pulling 19f32ed on SX91:compact-struct into d5cfd5a on 3Hren:master.

[SX91]

I would like to change enum's representation to something like:

[idx] for unit variant
[idx, value] for newtype variant
[idx, [...]] for other

@3Hren what do you think? That would make it compatible with Haskell's data-msgpack library and optimize complex structures layout a lot (reduce more of those nested arrays).

[3Hren]

Again, I'm not strictly agains it. All that matters - is backward compatibility. I think we should consider some kind of swappable policies for serialization. Deserialization must support all these ambiguous cases.

[3Hren]

It is possible to support both old and new deserialization schemes with the cost of some CPU cycles.

[SX91]

I guess it would introduce some ambiguity and make it difficult to work with nested types. Handling of something like struct A(Vec<i32>) would require some code to decode it correctly.
Is it really necessary?

[SX91]

@3Hren what needs to be done to get this merged?

[3Hren]

I'll check in 2 days. Serialization is fine, need to check deserialization. Completely burrowed into other projects :(

[3Hren]

At last I have some free time. Checked - no breaks for me! LGTM.

Variants, I think, must behave the same way. Units are doubtful, yeah. Generally speaking for serialization I want to provide options how to serialize ambiguous things, like unit structs. On the other hand deserialization must support all possible variants automatically.

I'll do these myself.

[3Hren]

Added in #146.