(Draft) Implemented basic run-time byte order.

[Kixunil]

This allows people to match on byteorder run-time, simplifying some implementations.

Closes #95

[Enet4]

Can we have this without associated consts? They are still a fairly recent feature, and this crate needs to support a wide audience.

[Kixunil]

Hmm, good point. Maybe feature-gate them for now?

[BurntSushi]

@Kixunil Sorry it has taken me so long to look at this, but thanks for the PR! @Enet4 is right. I'd like byteorder to be as widely applicable as possible. And I'm not too keen on adding new features. Every new feature is another maintenance burden and another entry in the test matrix. The feature needs to pull its weight to justify such things. I've left a comment to try to help me understand what is actually desired here: #95 (comment)

[Kixunil]

To my knowledge, here are actually three cases in which "runtime" endianess enum is useful:

• In serialization/deserialization generators - one can write function that decides byte ordering based on configuration
• In case the format supports both orderings and provides a way to distinguish
• In case of non-std numbers (e.g. 256 bit integer), if one wants to implement read/write methods for them (so this crate doesn't need to depend on every other big number crate in existence).

I'm not sure how valuable are these features in your view. The nice thing is that they can be supported with a single type.

[BurntSushi]

This PR has gotten quite old at this point. I think byteorder is what it is, and for bigger API changes like this, folks should experiment in new crates.

[Kixunil]

Fair point. I might release a crate for this if I ever need it again. :)