Support selecting endianness for numeric types

[ygale]

Make it possible to specify the endianness of the serialization for numeric types.

This could be implemented as newtype wrappers LitteEndian, BigEndian, and HostEndian. Or it could be a bunch of separate combinators, as in binary and cereal.

[mgsloan]

Good ideas!

Newtype wrappers LitteEndian, BigEndian, and HostEndian

This would enable TH / generics to write your serialization definitions. I'm not sure how to make these work on larger datatypes (LittleEndian MyADT), or whether one would even want that.

HostEndian should be assumed. So that leaves us with explicit LittleEndian / BigEndian for the numeric types (probably everything Storable).

Or it could be a bunch of separate combinators, as in binary and cereal.

It makes a lot of sense to expose getInt32 / getInt32be operators from some module. This will allow for processing existing binary formats. While it'd be more consistent for these to start with peek, this would make it compatible with binary / cereal to aid porting! I've opened #35 on this topic.

[mgsloan]

One of the primary reasons store does not yet have machine independent serialization stuff is that I'd like to support it safely - #36 - and that's a fair chunk of work. It gets particularly complicated with better support for alignment #37

[ygale]

The only reason I included HostEndian is so that the current built-in default endianness is not exposed. That way it could later be changed without breaking code for people who care about endianness. Up to you whether that is worth the bit of extra noise.

Right, these only make sense for specific types that have built-in support for endianness. We could enforce that in the types if you want.

[mgsloan]

Based on the design in #36, LittleEndian would also be unnecessary, as it would be assumed and equivalent to HostEndian. So that leaves us with just a BigEndian that could be applied to numeric types.