feat(common): Improve _xorBuffer() performance

[dwatteau]

Thomas' original code had some logic to xor the values with 4 bytes at once, to improve performance.

However, this caused -Wcast-align issues on some platforms (see issue #10 for more details). This code was then removed in commit ecff30b.

This new approach restores a bit of this logic, but it's now done in a way to avoid unaligned loads. It seems to work on that old mips64el board I have.

TODO:

• do more tests
• see if it does make a difference, regarding performance (is there a real bottleneck there?)
• don't forget to test with different compilers: GCC, Clang, MSVC…
• check everything's still OK on a big-endian environment
• see if it improves issue [Performance] GCC builds are ~30% faster than Clang/MSVC builds #4, in some way

[dwatteau]

It looks like most of the _xorBuffer() calls are made on very small buffers (few bytes), where this optimization pipeline won't bring much (it could even be a bit counter-productive, so I've added a if (X > xxx) check).

==> to be checked a bit more, though.

[dwatteau]

I'd need to add a logger to register how often the if (n >= 16) case is triggered, in some typical imports/exports (on various games).

If it's very rare, then this optimization is probably just not worth it, and could be discarded (still, some unrelated parts of this PR would be worth a cherry-pick).

==> also see if 12 or 16 is the best value?

[dwatteau]

Well, it's just a single example, but with scummtr -g monkeysega -if original-text.txt I have:

• 2802 hits for the (n >= 16) case
• 617778 hits for the (n < 16) case

==> so, at least for a V5 game like Monkey1 Sega CD, it looks like _xorBuffer is called many times, mainly on very small buffers. So there, the optimization is called very rarely, and so it won't much effect, in the end.

And if I move the threshold to (n >= 12) (probably the lowest value where setting up the "optimization pipeline" could be worth it, maybe), I have 3476 hits for 614308 misses.