Move rlgl and audio functions into separate libraries

[gpetiot]

As suggested in the README, this splits raylib into 2 new libraries: raylib-raudio and raylib-rlgl.

A possible improvement would be to restructure src/c into src/c/{raylib,raygui,rlgl,raudio} instead of src/c/{config,functions,stubgen,types}. I don't know what would be easier to maintain.

[tjammer]

Thanks for tackling this issue!

What I had envisioned was the following:
There is only one single raylib package which comes with several libraries. So in opam your game would only depend on one raylib package. If you use raylib (via (libraries raylib) in dune) you can use only the raylib core module. Then using other raylib modules requires pulling in additional libraries, e.g. (libraries raylib raylib.audio raylib.rlgl).

For inspiration I suggest the llvm package, which is structured like this (versions up to 14, at least).

As for the module granularity: Carving out audio and rlgl is as good a starting point as any. Ultimately, I think it makes sense to follow the module split of upstream raylib, which is outlined in this cheat sheet https://www.raylib.com/cheatsheet/cheatsheet.html. But you wouldn't want to do this manually, most likely. I have some (unfinished, borderline unusable) code in src/util to semi-automate the binding generation. It takes the json description of the raylib API as input. This description already separates everything into said module structure.

When we have this structure set up, it'd also make sense to move the gui binding from their own package into the raylib package as a sub-module.

Just to be clear: I don't expect you to do all of the work with this PR. I just wanted to outline a possible future state of the module split.