Consider adding a new CLI command to install packages from remote repositories (?)

[rdw-software]

Goals:

• [ ] Can download and install packages from LuaRocks
• [ ] Can download and install packages from Lit
• [ ] Can download and install packages from GitHub
• [ ] Can download and install packages from self-hosted (arbitrary) git repositories
• [ ] Installed packages are placed in a standard location (e.g., ./evo/<org>/<package>)
• [ ] They can be loaded with a simple import (similar to require, but with extra features - TBD)
• [ ] They can be loaded from inside a zip app (if current executable is zip app, load from VFS - else, load from disk)
• [ ] They are added to the executable created via evo build
• [ ] Only Lua packages need to be supported (for now) - it might be useful to also download SO/DLL from GitHub releases?

Note: This doesn't involve any actual package management or dependency resolution. No reinventing the wheel on that front!

Why? Allows moving some parts out of the runtime (see #280 ), while still allowing apps to use, say, WebViews, with ease.

---

May require (pun intended) splitting into multiple issues as there are some complexities when it comes to import and zip apps.

For some additional constraints and design issues that need to be considered, see https://github.com/evo-lua/internal/issues/1

[rdw-software]

From experience, this is opening a whole can of worms (see luvit/evo-luvi). Not sure if it's worth it, will have to consider trade-offs.

I definitely would prefer using the existing package managers (or at least repositories) and let this be a dumb libgit clone/curl fetch.

[rdw-software]

For packages that require native code, there are effectively three issues:

1. Some might require glue code that interacts with the runtime/interop layer (or other FFI bindings), such as GLFW/WebGPU
2. The LuaRocks approach of building binaries (DLL/SO) on the user's machine often fails spectacularly, at least on Windows
3. Shared libraries can't be loaded from zip apps at all, so deploying just a single binary becomes a large headache (if desired)

I think the simplest solution to these problems is:

1. This has to be built into the runtime itself, as it currently is. Hopefully it won't be an issue (overhead/cannot move things out?)
2. Building things on Linux is easy, so just download prebuilt artifacts from GitHub releases (works for Windows at least). If they don't work for some reason (glibc), packages could provide a script to build them - maybe ninjabuild.lua even
3. I don't think supporting DLL/SO load from zip apps is possible, it would mean extracting first. So just ship zip app + DLLs?

[rdw-software]

If curl should be used (needs prototyping), then this requires #369 before it can be tackled.