So that they can find their respective resource folders.

* 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

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.

* 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

This reverts commit 540ad99442.

* update build.zig for zig 0.11.0

* fix build.zig in examples to install executable correctly

* discard build.zig, only use src/build.zig, to avoid annoying zig-out path problem

* update zig version note

* Revert "Fixed broken build.zig files. Now works with latest stable compiler (as of commit, latest is 0.10.1) (#3045)"

This reverts commit de748dfffe so that zig
build script works with master branch of zig.

* Added a note to build.zig files that denotes what version of zig they have been tested with.

* Standardised the note in the build.zig files

also, adds package manager support

* Add WASM support for Zig build

* Improve Web example building

* Remove emscript example building with Zig again

* Readd windows emscripten variables

Specifically, std.fs.OpenDirOptions struct no longer has the iterable
flag, now it's a standalone function call std.fs.openIterableDir

* Add zig buildfile for examples.

- `zig build` to compile all examples
- `zig build [module]` to compile all examples for a module (e.g. `zig build core`)
- `zig build [example]` to compile _and run_ a particular example (e.g. `zig build core_basic_window`)

You can use `-Dtarget=` to compile for a non-native platform, such as
`zig build -Dtarget=x86_64-windows-gnu` to compile from Linux to
Windows.

* Skip pthread example on Windows.

* Select appropriate lib file based on target.