Separate data-msgpack-types and serialisation implementations.

[iphydf]

We are currently tied to the binary package for serialisation. While very elegant, it may not be the best performing binary serialisation library. store seems to be faster. By separating the types and the specific serialiser, we can give the user a choice, and we can provide at least two implementations: one correct one (the existing one) and one fast one. We can then do random quickcheck-style equivalence testing between the two to make sure the fast one is also correct.

[SX91]

Also we need to extend (well, actually (re)write) documentation to point that data-msgpack is required for encoding/decoding (with binary) only, for MessagePack instances data-msgpack-types (or data-msgpack-class?) would be enough.

[SX91]

@iphydf if you could make a separate repo for types (or class, or object, whatever), I'd move all types related code there as a PR.

[iphydf]

Done: https://github.com/TokTok/hs-msgpack-types

[SX91]

Do we need a re-export modules like Data.MessagePack.Object etc? I've put all types modules to Data.MessagePack.Types.*.

[iphydf]

I don't know. So far I've been limiting the number of exposed modules, which gives some freedom to restructure and rearrange data and code. Perhaps a single Data.MessagePack.Types module re-exporting those would be good as the public API? Currently (in master) we don't expose .Object directly.

[iphydf]

Done in #43.