Endianness Considerations

[daxpedda]

After a long discussion in #104 (comment), we came to the conclusion that we should consider endianness when appropriate, this is mainly examples, tests and documentation.

Especially this line:

softbuffer/src/lib.rs

Line 340 in fcda747

/// 00000000RRRRRRRRGGGGGGGGBBBBBBBB

is actually just wrong. This worked so far because literals in Rust are written in big-endian, so if you write it as 0RGB, it will come out as BGR0, because most systems are little-endian, but BGR0 is actually the correct layout.

---

I would like to mention that I'm strongly in favor of changing the current buffer from [u32] to [u8], which seems like a much more user-friendly API to me and also makes most of the endianness considerations go away.

The main concern @ids1024 had about this is performance, which could be addressed by leaving the buffer as a [u32], but expose it as [u8] in the Deref implementation, we could still introduce a as_u32() method then. Though I would like to see a benchmark showing an actual performance regression before we put effort into something unconfirmed like this.