Enable loading dynamic libraries from the LUAZIP virtual file system (with a fallback for ffi.load for regular apps)

[Duckwhale]

Complimentary to #482, it should also be possible to load dynamic libraries (using the FFI) from the virtual file system. In-memory extraction and loading doesn't work since DLLs can only be loaded from disk. So a self-extraction mechanism is needed.

Goals:

• Applications can elect to use vfs.loadlibrary (or similar) if they want to support LUAZIP deployment
• If a DLL/SO needs to be loaded, it is extracted to a temporary directory (using uv.os_tmpdir) first
• Error messages should be clear in case of DLL load errors or if the file isn't found
• The original ffi.load function shouldn't be overridden or modified in any way, similar to the require policy

Roadmap:

• Implement vfs.loadlibrary to enable loading dynamic libraries from the VFS
  • If the executable isn't a LUAZIP app, it should just be aliases to ffi.load (so that things "just work" by default)
  • If it is a LUAZIP app, the actual VFS lookup functionality should automatically be made available
• Update the hello-world-app test to exercise the new functionality
  • Create a hello.dll (or libhello.so on macOS/Linux) library that's compiled into the hello-world-app archive
  • Modify the entry point (main.lua) so that it tries to load the library via vfs.loadlibrary
  • Run the main.lua entry point as part of the test so that it falls back to ffi.load when using vfs.loadlibrary
• Update the relevant parts of the documentation that still mentions dynamic libraries cannot be loaded from the VFS