Pefixing/Suffixing some data type identifier in the variables is not a convention used in raylib, just reviewed it for consistency...

Still, I kept the *Rec suffix in some functions.

Make model collision function call the mesh function.

WARNING: OBJ loading is broken at this point...

* allow for multiple materials in obj files also fix obj_loader hash map issues

* minor fix for warning

Co-authored-by: codifies <nospam@antispam.com>

This redesign allows more flexibility when creating RenderTexture and a simplification (and hopefully removal) of `GenTexture*()` functions, that should not belong to this model but the user code, due to the use of custom shaders.

Also, this new API opens the door for a possible GBuffers type and advance rendering possibilities...

Some functions of the API have been also simplified or even removed.

rlgl module can be used as an standalone library, so, a version for the library has been added: v3.1.0, matching current raylib version.

* MeshSmoothNormals() by average

* wrong comment

* spelling

* use correct function naming convention

Co-authored-by: frithrah <simon@frithrah.com>

This change could introduce an issue on dataSize precalculation...

Just flipped the signs of `n5` and `n6` at lines `2021` and `2022`.

Those functions could be very useful for custom triangle data drawing, using internal batch system.

Most warning were related to types conversion (casting required) and unsigned/signed types comparisons.

Added preprocessor directives (_CRT_SECURE_NO_DEPRECATE; _CRT_NONSTDC_NO_DEPRECATE) to avoid warnings about unsafe functions, those functions are safe while used properly and recommended alternatives are MS only.

Some external libraries still generate warnings.

There are multiple #define values around raylib, usually not exposed for redefinition, just reviewed all of them to allow users redefining them on compile time if required.

Also, multiple #define have been renamed and commented.

Actually this function is useless and potentially dangerous, internally, a shallow copy of data was done. Same could be accomplished accesing image.data directly.

Errores fixes:
models.c,2843 Either the condition 'fileData!=NULL' is redundant or there is possible null pointer dereference: fileData.
raudio.c,805, 806, 807, 808, %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'.

I don't like this solution but well... let's use it for the moment...

NOTE: Two libraries still use custom allocators: glfw and stb_vorbis

* Update GLTF support to include loading color for albdeo (saved in the color value of the materialmap), support occlussion and emmission maps.. as well as some quality of life updates.

* clean up to use single image

Just for clarification, no plans to remove libc dependency, just did some code analysis to see how much raylib depend on stardard C library. My conclusions:

 - stdlib.h: primary dependency is for malloc() and free()
 - stdio.h: primary dependency is for FILE access, maybe it could go through a custom ABI?
 - string.h: just around 8 functions required
 - math.h: just around 8 functions required
 - others: 1-2 functions required for some other headers