Handle CRe's weird-ass pixel-format once and for all

[NiLuJe]

We expect RGBA, CRe uses BGRX (well, alpha is actually sane, but inverted. Which, AFAIK, is usually a weird legacy PNG/Gif quirk or something, but, oh, well).

As discussed in koreader/koreader#7021

Depends on koreader/crengine#402

---

This change is 

[NiLuJe]

Now, while this is only actually an issue visible in native buffer grabs on RGB32, there are a couple of quirks to take into account:

• Handling the RGB <-> BGR inversion inside CRe was faster, and turned out to be not entirely insane, and didn't have many side-effects (but it did have some, c.f., Get rid of RevRGB & co crengine#402)
• Handling the alpha inversion inside CRe is completely unfeasible without basically rewriting every bit of color handling code to not be a special snowflake.
• Handling this in the native screenshot code is viable (c.f., the BGR swap on Kobo), but then, Android rears its ugly head: that'd be a pixel-loop in ffi/bb, in plain/FFI Lua, and as such, a big no-no because Android and mcode allocs and the JIT and everything being the worst.

So, this leaves handling it right after CRe's done with a buffer for a specific page, in C(++).
Which means an extra buffer walk, which tanks the performance a bit. Oh, well.

(FWIW, this is what the CRe Android GUI does, too).

[NiLuJe]

Oh, and as the actual performance hit is the buffer walk in itself, not so much what we do inside, I moved the full conversion in there, to get rid of the various potential quirks of the in-CRe BGR swap.

[Frenzie]

Fine by me.

[poire-z]

Looks indeed like a long walk... But I trust you it's for the best.
That's only for emulators and android, our B&W eInk devices won't suffer, right ?

I guess at one point, you'll try optimizing it by using parallel same operation on multiple byte, the neon stuff, if I got that right :)

[NiLuJe]

Yeah, that's only the color codepath (so, yeah, essentially Android & SDL).

And that's indeed something that could potentially be vectorized, but again, the issue isn't so much the cost of the operation being done, but the simple fact that we're churning over the buffer again. But still, probably some potential for improvements if someone were to take an interest in it ;).