* fix minor bugs and errors (x86) for the RGFW platform, update RGFW platform license, update makefile info for RGFW platform

* revert

* (RGFW) (winapi) fix mouse hide bug when cursor changes

* ensure PLATFORM_SHELL is defined (PLATFORM_RGFW)

---------

Co-authored-by: ColleagueRiley <ColleagueRiley@gmail.com>

Redesigned function to only consider separation between the end of vertical size of one line and the beginning of next line

The `RL_CULL_DISTANCE_` definition remains as the initial value
of the variables.

Basic usage can be:
```c
#include <raylib.h>
#include <rlgl.h>

rlSetClipPlanes(RL_CULL_DISTANCE_NEAR, MY_CULL_DISTANCE_FAR);

if (must_reset_clip_planes)
    rlSetClipPlanes(RL_CULL_DISTANCE_NEAR, RL_CULL_DISTANCE_FAR);
```

* Fix several non-functional `target_compile_definitions`

* Avoid hardcoding the default vertex attribute locations

* Implement functional `rlNormal3f`

* Add normal definitions for `DrawCube`

* Update the basic lighting example to use `DrawCube` and `DrawPlane`

* Remove support for 0.11.0, and make build script more idiomatic
+ remove all 0.11.0 compatibility functions
+ remove most LazyPath .path variants
  + I didn't touch emscripten, I don't know if its relative or absolute
+ change all absolute paths to use .cwd_relative
+ only use the builder allocator
+ have local dependencies use the package manager
+ make adding raygui more flexible
+ use zig-cache for generated wayland files

* Remove support for 0.11.0 in examples/build.zig

* update examples further and add clarifying comment on addRaygui

This reverts commit c1fd98591d.

Fix typo

Less matrix operations doing.

* cmake: For SDL, disable rlgl_standalone

* cmake: Only build rlgl_standalone when on Desktop, and not shared libs

* Screen/world-space related functions rename

* Update raylib_api.* by CI

---------

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

Tutorial on how to use bones as sockets to calculate the position of something.

I tested this with CMake. I don't know if the examples makefile
currently handles this case.

Currently, every example fails linking likeso:

[  3%] Linking C executable audio_mixed_processor
/usr/bin/ld: ../raylib/libraylib.a(raudio.c.o): undefined reference to symbol 'exp@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Apparently, linking libm explicitly is the solution.

Fixed a grammatical error by removing "are" to change `... but some are have multiple purposes ...` to `... but some have multiple purposes ...` in `textures/textures_image_generation`

The purpose of this directory in GLFW is to provide some headers that
"mingw.org" doesn't. Raylib has long been unable to build with mingw.org
due to using certain symbols that aren't exposed in their headers.
(_ftelli64 and _access, among others.). Mingw-w64 already has the
necessary headers included, and doesn't need any of these external
implementations. For some reason, this also causes the following error
when building with Visual Studio's clang:

clang  -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing  -std=c99 -O1 -Werror=implicit-function-declaration -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw
In file included from rglfw.c:61:
In file included from ./external/glfw/src/init.c:30:
In file included from ./external/glfw/src/internal.h:331:
In file included from ./external/glfw/src/platform.h:31:
In file included from ./external/glfw/src/win32_platform.h:70:
external/glfw/deps/mingw\xinput.h:227:26: error: a parameter list without types is only allowed in a function definition
  227 | void WINAPI XInputEnable(WINBOOL);
      |

If the last -Iexternal/glfw/deps/mingw is removed, the build works fine.

So, this workaround causes other problems, while not actually helping
raylib.

0bb605cd79/src/CMakeLists.txt (L272-L279)

GLFW's CMakeLists.txt first checks if either dinput.h or xinput.h are
provided by the toolchain, before telling the compiler to search for
headers in that directory. For EVERY compiler that can build raylib,
this is true.

In summary: This directory causes issues when building with some
compilers, and every toolchain that needs this workaround can't build
raylib anyway.

Reviewed flags formating

* update build.zig for latest zig 0.12.0dev while still allowing 0.11.0

* update examples/build.zig and add nicer message for type mismatch

* Review UnloadAutomationEventList

* Update raylib.h

* Update rcore.c

* Update core_automation_events.c

* Fix mistake

* fix for deferred rendering example.

* missed defines to build.