Make rgb565 conversion algorithms a bit better

[LoganDark]

The old algorithm has some unpleasant tinting. Native components [0xFF, 0xFF] don't result in rgb components [0xFF, 0xFF, 0xFF] but rather [0xF8, 0xFC, 0xF8]. This affects screenshots for example.

Obviously some fudging is needed in order to come up with the "extra resolution" in rgb8 to make the mins and maxes match up. Roundtripping from 565 -> 888 -> 565 is still a thing. And now it's a part of the test suite, which verifies that every rgb565 value can be roundtripped to rgb8 and back. And that rgb565 -> rgb8 conversions behave properly.

The new conversion routines still only use integer arithmetic. I haven't benchmarked them but they should actually be slightly faster than the old routines.

Note that I tested these on my desktop machine which required #92 in order to get libremarkable to build. Just a preview of how useful that can be.

[LoganDark]

This actually fixes a bug in color::to_rgb8 that results in r and b being swapped (I think?)

In any case everything works now and everything interacts perfectly with the simulator I've set up...

1. builtin colors look correct
2. round tripping works
3. color::WHITE shows as #FFFFFF white
4. color blending on the buffer is correct

[bkirwi]

Solid improvement, and thanks for the tests!

Haven't heard of any issues building on desktop before... which dep failed to build / any idea why?

[LoganDark]

I had issues building evdev and epoll since I was cross-compiling for Windows (WSL 1 - I don't like VMs - no graphics support). #92 adds the ability to exclude those from the build. Although it looks like nobody's wanted to touch it for a while - now that I depend on it, I need it merged at some point but I fear that it's too big/complicated of a change now.

I've been testing this by merging it into #92 on my local checkout and then running cargo test --target x86_64-unknown-linux-gnu --package libremarkable --lib framebuffer::common::rgb565_conversions --no-default-features --features framebuffer-types -- --exact. It's a mouthful but it works!

There's also the visual test of running my app on #92 with and without this PR. Without, color blending is totally scuffed, but with, it works fine. It's literally a case where color::RGB(255, 0, 0).to_rgb8() will return 0, 0, 255 on the old version

[bkirwi]

I had issues building evdev and epoll since I was cross-compiling for Windows (WSL 1 - I don't like VMs - no graphics support).

Make sense - thanks!

[LoganDark]

I added tests for the specific colors, and I'm 100% sure that red/green were swapped. I'm also 100% sure that the endianness is CORRECT this time - both in terms of the byte order of the u16 and the order of the components in that u16. Test passes. Phew........

[LoganDark]

You should probably squash all these commits when you merge.

[LoganDark]

Just for the record the endianness is now correct and proven to work correctly on-device. Since the encoding and decoding algorithms match, I was able to run screenshot with #96 to get this beauty:

to prove beyond a shadow of a doubt that YES, we understand the rgb565_le format correctly. ([gggbbbbb, rrrrrggg])

For those following along at home, xochitl only writes color information to the framebuffer if screenshare is turned on.

[fenollp]

@bkirwi Next time maybe select the "Squash and merge" option?