Rewrite purego version to use libffi embed .dll/.so files

[JupiterRider]

The purego version of raylib-go currently only works on windows. That's because passing and returning structs is not supported. A workaround would be to use my libffi binding: https://github.com/JupiterRider/ffi
There is also an example: https://github.com/JupiterRider/ffi/tree/main/examples/structs/raylib

If we use libffi, we could use the same codebase for every platform, but this would mean that the user needs raylib and libffi as .dll/.so on his computer. To get around this, we could "go:embed" these files.
To ensure that these blobs are safe and not malicious, we need to setup our own build pipelines. Here is an example how Monogame does this: https://github.com/MonoGame/MonoGame.Library.SDL

@gen2brain What do you think? Would you mind setting up a new repository to build these libraries?
We would need raylib for every Platform (Windows, macOS, Linux) and libffi for Windows and macOS.

[gen2brain]

@JupiterRider I am for it if you are willing to work on the libffi bindings. There are a lot of structs there.

I'm not too fond of the idea of a new repo though, what would it contain, there is no reason for source code to exist there when it can be fetched. And We are missing some platforms like darwin/arm64, windows/arm64, linux/arm64, linux musl, etc. I think that should not be a blocker, as long as there is a build tag, something like noembed maybe, so if users don't trust, they can use whatever they want. I already have some projects where I bundle the libraries, and I can just cross-compile everything from my laptop, much easier than doing it one by one, yeah users also have a choice and nobody complains. We can maybe build the osxcross toolchain with GitHub actions for aarch64, or llvm-mingw for windows/arm64 but let's focus on that later. I can build and prepare all the libraries manually for now.

We can just gzip the shared libraries and unpack in /tmp on init. That would be just a few ms and it saves the binary size.