Stance on packages using non-C native modules

As of now, most packages that I can find in the index are written either fully natively in Janet, or with C components, which then are built by jpm. But modules can be written in other languages that can compile down to a .so/.a that's suitable for linking with Janet: using bindings such as [jzignet](https://github.com/greenfork/jzignet) for Zig or [JanetRS](https://github.com/GrayJack/janetrs/) for Rust, it's possible, through some jumping of hoops, to create native modules that can even be used as though they were any other native module, including compiling into a static binary.

Building a non-C native module usually has extra dependencies though, such as the native language compiler and possibly the bindings (as in the case of Zig which doesn't have a package manager of its own like Rust's `cargo`, at least not yet), and therefore just `jpm install`ing such modules is likely to not work if the user doesn't have the necessary ambient dependencies installed beforehand.

As such, I wanted to raise a question whether such non-C native-using packages are in scope for `pkgs`, given their requirement for ambient dependencies that I don't believe jpm can currently express. If so, I feel like there should also be a base expectation of jpm being able to build such a package in its entirety (e.g., via `jpm build`, presumably using jpm's `shell` fn), if the necessary dependencies are present.

Review the issue's examples of jpm install, jpm build, and jpm's shell function, along with the jzignet and JanetRS bindings. The work would first require deciding whether non-C native modules are in scope for pkgs, then documenting the expected ambient dependencies and build behavior.

Written by the indexing model from the issue text.