bug fix: incorrect RGBA values for some embedded textures

[rafccq]

fixes #50.
I found that the RGBA32 textures embedded in the drone guns models are already in little-endian byte order, so I byte swapped them at preprocess time so that they will be byte-swapped again by the renderer, returning to the original state.

Needs more testing though, meanwhile I will check what are all the other embedded textures and how they're rendering.

[fgsfdsfgs]

The texture swapping is kind of all over the place. The renderer expects everything in big endian, unless I changed that somewhere by mistake. I'm not sure why the embedded RGBA32 textures specifically would be in LE.
Note that theoretically the texture can be bigger than width * height, because rows can be aligned to a 8-byte boundary, though in practice with RGBA32 textures this is unlikely because width would probably be an even number.

[rafccq]

I still can't understand why there are embedded LE bytes when the target machine is BE. Also I wonder how GlideN64 deals with that.

The renderer expects everything in big endian, unless I changed that somewhere by mistake

That's correct, it will always byte-swap the textures, it hasn't changed.

[fgsfdsfgs]

I guess I'll just merge this and we'll see if it breaks anything.