Always return little-endian packed value in Rgba8::to_u32

[tomcur]

(And PremulRgba8.)

If the intention is for the bytes of R, G, B and A to always be in the same memory order, I believe this patch is required. The docstring on the method suggests that's the intention.

In the order of memory of Rgba8::to_u8_array, the red channel is at the lowest memory address and therefore (in little endian) the least significant byte. On a big endian system, using from_le_bytes would move the red byte to the highest memory address.

[DJMcNab]

This function has gone through all three of these functions in the last couple of weeks.

We really need some miri testing for a big-endian system...

I think... that I agree that this is right.

[tomcur]

The invocation

$ cargo miri test --target s390x-unknown-linux-gnu --features bytemuck -- rgba8::

fails on main:

running 2 tests
test rgba8::tests::bytemuck_to_u32 ... FAILED
test rgba8::tests::to_u32 ... FAILED

failures:

---- rgba8::tests::bytemuck_to_u32 stdout ----
thread 'rgba8::tests::bytemuck_to_u32' panicked at color/src/rgba8.rs:139:9:
assertion `left == right` failed
  left: 67305985
 right: 16909060
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
note: in Miri, you may have to set `MIRIFLAGS=-Zmiri-env-forward=RUST_BACKTRACE` for the environment variable to have an effect

---- rgba8::tests::to_u32 stdout ----
thread 'rgba8::tests::to_u32' panicked at color/src/rgba8.rs:119:9:
assertion `left == right` failed
  left: 16909060
 right: 67305985

It passes with this patch.

[waywardmonkeys]

I've done a PR with Miri in CI in #101 ...

[waywardmonkeys]

Okay ... and we'll use Miri in CI to keep things right going forward!

[waywardmonkeys]

Going to merge this now so that I can perhaps do the release now. (Breaking the usual policy...)