Use GL_BGRA for Dreamcast GLdc fast path

[cypressru]

This puts raylib on GLdc's fast path, drastically reducing overhead. Performance improvement: ~40 FPS -> ~59 FPS in example scenes.

[meisei4]

Was meaning to comment here but hadn't gotten around to it and just want to make sure i dont forget, I wanted to mention this will result in R and B channel reversal for any mesh drawing that involves manual color management semantics contract:

i.e. Because Color, is still under an r, g, b, a ordered semantic contract:

https://github.com/raylib4Consoles/raylib/blob/master/src/raylib.h#L247-L251

• for any manually managed mesh color buffers (e.g. direct mesh.colors writes, generated/procedural vertex colors), it will now require R and B reversal in the Colors to avoid behavior changes

Here is a videos RGB on top and BGR on bottom of a painting tool that i use to test vertex colors for raylib4Consoles showing the difference of behavior, its the same mesh looking at the same model position, using the same brush color to paint on the meshes vertices etc etc):

RGB.mp4

BGR.mp4

Im not sure what the correct solution would best be for this (especially if it really is something that should just be top level no fallbacks and we just reverse the Color struct semantics for all of DREAMCAST stuff if its optimal, that would be coolest imo if this is nontrivial gainz, otherwise this could be confusing, im sure GLdc has some convention for this though?

Also im wondering @cypressru does this perf increase require you to account for a like preemptive R and B swizzle/(swap?) in your meshes?

[meisei4]

This might need another review I think now that GLdc vertex structure redesign is taking a new shape. I snuck in what I think could result in clean raylib fast path routing in PR pending review here: https://gitlab.com/simulant/GLdc/-/merge_requests/170 GL_BGRA seems to be gone, but wouldn't be surprised if it comes back

Updating this ticket for documentation purposes again.