This function is not required, users can check it with `GetGamepadName()`

* - support create OpenGL debug context in OpenGL 4.3

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

* Reviewed OpenGL Debug Context

Those defines are only used inside `rlgl` module

Co-authored-by: Michael <michael@cubeofb.org>

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

* [rcore] fix rpi4 Failed to get DRM resources

card1 is not always the the correct card to use on rpi4
rpi os finds the correct card and links it to /dev/dri/by-path/platform-gpu-card during boot.
this fix makes sure that we always point to the correct card on rpi4

* Update rcore.c

raylib modules have been slightly renamed to add some identity and note that they are independent modules that can be used as standalone separate parts of raylib if required.

The renamed modules are:
 - `core` -> `rcore`
 - `shapes` -> `rshapes`
 - `textures` -> `rtextures`
 - `text` -> `rtext`
 - `models` -> `rmodels`
 - `camera` -> `rcamera`
 - `gestures` -> `rgestures`
 - `core` -> `rcore`

All the build systems has been adapted to this change.

Specifying a fixed seed for the random number generator is often
used in games for various reasons.

By adding an api function for seeding the random number generator
we solve two different problems regarding the seeding:

1) The underlying RNG implementation does not leak to client code
   (as would be the case if we called srand directly from the
   client code)
2) Seeding the RNG would be simple from other programming languages
   (especially in cases where calling libc functions is non-trivial)

* implemented GetGamepadName for emscripten

* updated gamepad to use existing name as arary

* removed unnecessary platform_web check

- ADDED: `GetTouchPointCount()` to core module, removed from gestures module.
 - Support multiple touch points: `MAX_TOUCH_POINTS`.

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

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

Legacy keyboard support was blocking the render loop, also it was keeping the last key status until the next key.

After lot of investigation, I'm afraid I'm removing official UWP support from raylib, I'll keep the current implementation in a separate branch (UWP), just in case. It seems Microsoft is trying to replace UWP in the long term, they announced lack of support for the new WinUI 3 and they seem to be moving to Windows App SDK.

Also, on current implementation, the code is divided between raylib and the example, requiring multiple callback hooks, making it difficult to follow and maintain.

And realistically speaking, raylib is probably not the best option for anyone willing to target UWP, neither Xbox consoles.