Implement the `sys` primitive

[masak]

This one has fallen by the wayside so far, because it doesn't really interact with anything else in the specification. In fact, it's only ever mentioned once.

I assume sys calls should be blocking. It's an open question what they should return — the command's output (like Perl's qx) or the exit status (like Perl's system)? I'm torn; it feels like either could be useful.

[masak]

It's an open question what they should return — the command's output (like Perl's qx) or the exit status (like Perl's system)? I'm torn; it feels like either could be useful.

Hey, how about — neither?

Hear me out. Taking a leaf from Kernel's API sensibilities, sys already has a side effect and therefore it shouldn't have a return value.

• The command's output could be captured with the same mechanism as we capture output in Bel itself — by dynamically re-binding out. The underlying assumption here would be that the dynamic binding of out somehow "survives" into the process. Since the sys call is blocking, this makes some kind of sense, even.
• The exit status could be stored in some unrelated global value in the environment... let's call it process-exit-code. This one can be nil before any sys call has been made. If someone wants to run sys and get the return code as a single call, we could define a utility function for that.