Fix broken C version of MulMatricesC

Me and cxd4 (Hatcat/mephostophilis) stumbled upon this while backporting some stuff to the libretro version.

The C version of MulMatricesC appears to be totally broken. I guess this went unnoticed before because it would default to the SSE2 codepath version on regular desktops.

Read the explanation by cxd4 here:

https://github.com/libretro/mupen64plus-libretro/pull/159

' repairs were made to the ANSI C code which had broken texture elements in the backgrounds of games like Super Mario 64. In addition, the new ANSI C function is written in vectorized loop style, such that GCC can very easily create the SSE instructions relevant to said loops in a manner perhaps more optimized than the original SSE-fixed code.'
That's fine.  In particular, my point is, only the C code (also thought of as the "auto-vectorized" code) has universal meaning.  Anything else like inline assembly, or assembly language intrinsics, is in the eye of the beholder and not naturally readable code to everyone--because, its readability is dictated more by the target processor.

For example, suppose you might prefer the intrinsic use:
`ALIGNED int32_t a[4], b[4], c[4];
int main(void) {
    *(__m128i *)c = _mm_and_si128(*(__m128i *)a, *(__m128i *)b);
    return 0;
}`

However, I find it even more readable to both the human and the compiler (for better optimizations outside the version of the SIMD instruction set architecture assumed by the usage of that intrinsic) to instead say:

`int a[4], b[4], c[4];
int main(void) {
    register unsigned int i;

    for (i = 0; i < 4; i++)
        c[i] = a[i] & b[i];
    return 0;
}`

Although the name of the `_mm_and_si128` intrinsic is self-explanatory as to the operation of the code, the algorithm itself is more readable and more natural when using C code (and the compiler is left to generate what should be the best choice of SIMD intrinsic for and'ing all elements).  This commit probably isn't the best example of that, however--you're welcome to disagree whether my C loops are as readable as some of the old code.  The gist of it may have been portability, but I thought it was more readable to divide each parallelized step of the overal algorithm into its own loop.  The original C loop code you had was much better than mine, thougin terms of shortness and brevity--maybe open to interpretation on the parallel steps what goes on.  So I think it's fine if certain sketchy examples of this practice come up that you like to comment about.