Collection of correction patches for new-vertex-structure

patches for:

1. Non-fast path shared current color state

   - simple fix (secondary color remaining WHITE i did not touch, but was wondering if it really should be WHITE? just double checking.)

2. {R, G, B, A}8IDX swizzle indexing conventions

   - consistency patch for all color array ARGB RGBA channel mapping/swizzling (fixes foreign color semantics, e.g. raylib rgba conventions)

3. 4ub -> 4f color conversion handling (inside draw "fast path" and normal path )

   - This one i have snuck in here perhaps... it seemed straight forward and it also funnels raylib into fast path and general compatability with previous expectations i think

   - I am not 100% sure though. If this is inappropriate i would very appreciate any advice as to where this should be handled, i think from interfacing sides it becomes strange (e.g. https://github.com/raylib4Consoles/raylib/pull/15/changes/b26aa8cba0ddc4729256f9e07e4465a7900ca13b was an attempt to address this i think, but now with new vertex structure it becomes obsolete i believe

4. Texture transparency/alpha preserving allowance with new "textures-always-on convention"

   - this allows for alpha preserving now for the new default textures always enabled convention. Without this alpha transparency (for example driven by vertex colors as i am testing) becomes unstable

   - this is my first time touching PVR directly so i hope it can be reviewed to make sure i understood how these flags work it seemed straight forward and my tests fixed all the transparency issues

NOTES:

• I have found that with 64 size Vertex now, many of my more vertex heavy tests become very unstable on emulation/Flycast vs actual hardware testing, as well as general lighting tests become unstable as well, unsure if its related to just general (what i imagine are "obvious"?) trade offs of this more unified structure, but i would be interested to see if a split of 32 and 64 options could somehow be achieved?

TABLE FOR unlit and lit unindexed sphere draws from GenMeshSphere https://github.com/raysan5/raylib/blob/master/src/rmodels.c#L2937

MATHS for unindexed sphere:

triangles = 2 * n * (n - 1)
submitted vertices = triangles * 3
bytes = submitted vertices * 64

unlit unindexed sphere:
n = rings and slices of sphere mesh (set equal)
  n   triangles   submitted vertices    *64 bytes   
---------------------------------------------------
| 20 |       760 |              2,280 |   145,920 | <- visible
| 22 |       924 |              2,772 |   177,408 | <- visible       
| 23 |     1,012 |              3,036 |   194,304 | <- flycast just stops drawing around here
| 24 |     1,104 |              3,312 |   211,968 | <- no geometry shows up  
| 32 |     1,984 |              5,952 |   380,928 | <- no geometry shows up   
| 45 |     3,960 |             11,880 |   760,320 | <- no geometry shows up  
| 53 |     5,512 |             16,536 | 1,058,304 | <- flycast starts stuttering (e.g. audio playing in the background begins to clip and stutter and the whole flycast external frame updates stutters 
| 55 |     5,940 |             17,820 | 1,140,480 | <- extreme stuttering


single position light lit unindexed sphere:
n = rings and slices of sphere mesh (set to equal)
  n    triangles   submitted vertices    *64 bytes   
----------------------------------------------------
|  6 |        60 |                180 |      11,520 | <- geometry visible no stuttering
|  8 |       112 |                336 |      21,504 | <- geometry visible begin to notice flycast stuttering
| 10 |       180 |                540 |      34,560 | <- geometry visible but extreme stuttering with flycast external app frame rate almost same with audio playback

• Unaddressed but with the now default enabled white texture, funky things can happen when you animate/dynamically update texcoords of mesh structures without setting a custom texture in place of the 8x8 WHITE one now (strangley this behavior differs between flycast and real hardware, the 8x8 textures texels start to kind of corrupt, but i didnt look into this deeper since animating texcoords without a texture provided is likely programmer error, just thought id mention it)