* - support create OpenGL debug context in OpenGL 4.3

* - additional events in debug message
- fixed glEnable(GL_DEBUG_OUTPUT)

* Reviewed OpenGL Debug Context

Now uses correct version.

- Support Compute Shaders by rlgl API
 - Support SSBO by rlgl API

* Add basic compute shader and ssbo support in rlgl.

* Add rlBindImageTexture (untested), now requires SUPPORT_COMPILE_SHADERS

* Delete glad.c

* Delete glad.h

* Delete khrplatform.h

* Revert to previous glad.h

* Remove "glad.c"

Co-authored-by: Ray <raysan5@gmail.com>

`RLGL.State.vertexCounter` is a generic counter and it's reused for all `rlRenderBatch`, actually, once render batch is filled, required vertex count is provided through the draw calls, so, the total accumulated count of vertices is not directly registered inside the rlRenderBatch.

`RLGL.State.vertexCounter` keeps that count but one possible improvement(?) could be moving the `vertexCounter` inside `rlRenderBatch` to always keep a register of the total accumulated vertices in that batch (despite that info is provided by the accumulated `draws[i].vertexCount`.

Simplifying, `RLGL.State.vertexCounter = SUM(draws[i].vertexCount)`

The decision to move the counter out of `rlVertexBuffer` is to keep only the data that I think should belong to `rlVertexBuffer` and make it more generic, aligned with raylib `Mesh` structure.

The decision to not add it to `rlRenderBatch` is because it could contain multiple `rlVertexBuffer` and it would be confusing (because it would only register the count of the last filled one).

Instead of registering vertex texcoords and colors on every call, we keep the last defined value and we record everything on `glVertex*()`. Actually that behavior is aligned with OpenGL 1.1 standard.

Following english rules, it should be singular name before Count.

Note that `extern "C"` calling convention only affects objects that need to be seen by the linker, in our case only functions... but it would also be required by global variables exposed, if any.

- ADDED: rlEnableColorBlend()/rlDisableColorBlend()

* GenMeshTangents Fix

* GenMeshTangents Fix - Comment Update

* GenMeshTangents Fix - Comment Update final

* Code Style Changes

* Code Style Changes Final

* Code Style Changes Final 2

* GenMeshTangents better handling for issue #1876

* GenMeshTangents better handling for issue #1876

* GenMeshTangents: Better fix for issue #1876

* vboId location fix

* rlUpdateVertexBuffer - bufferId is an unsigned int

This reverts commit a8e9e1387f.

Now rlgl uses the `Matrix` type, just make sure it has been previously defined somewhere... I don't like this approach but it's probably the easier one for the users... still looking for a better solution... maybe using something like
`#define MATRIX_TYPE`, so it can be checked in other modules.

rlgl has been redesigned to avoid any dependency to `raylib` or `raymath`, all functions using some of those libs have been reviewed.
 - REMOVED: `Texture2D`, `Shader` structs dependency
 - REMOVED: `Vector3`, `Matrix` structs dependency
 - REMOVED: raymath functions dependency, all required math is implemented in rlgl
 - ADDED: `rlMatrix` custom rlgl type
 - ADDED: `utils.c`: `rlMatrixFromMatrix()` and `rlMatrixToMatrix()` for a safe conversion between raylib<->rlgl matrix types
 - ADDED: `rl` prefix to all `rlgl` structs
 - Other small tweaks here and there

ADDED: rlGetPixelFormatName()