Expand Sys builtins

[shonfeder]

This aims at expanding the available builtins for interacting with the OS, as proposed in #427. I an opening this initial PR with just 6 additions, so I can gather feedback on whether the general approach and style is in line with your dev preferences.

I am happy to have this merged as is, if you are happy with it and would like contributions around this size (perhaps some tests should also be added? Could you point me to the right spot for those?). But I wold also be happy to gather feedback on the changes staged here, and then finish FFI for the following functions from Sys:

    external chdir : string -> unit = "caml_sys_chdir"
    external mkdir : string -> int -> unit = "caml_sys_mkdir"
    external rmdir : string -> unit = "caml_sys_rmdir"
    external getcwd : unit -> string = "caml_sys_getcwd"

[gares]

It seems some api need recent ocaml. I think we could document that, and use ppx optcomp to have the only in newer versions

[shonfeder]

Ah! I didn't see that about Sys.is_regular_file, we could skip adding that for now too? It's not really essential IMO. I'd be happy with just dropping that only sticking with stuff that is compatible with the current lower ocaml bound. WDYT?

[gares]

Ok drop it

[shonfeder]

I am just reworking the doc comments. I have put together some crude tests in shonfeder@f1e9d47 . This is enough to convince me that all the additions are working as expected, but they are not suitable for inclusion in the repo as is, because they do no sandboxing of the file system mutations. I could not find an existing mechanism for this within your current test harness (tho running the tests thru dune rules rather than make could do this for us). If you're happy merging without the tests, that's OK with me. If you'd like the tests, please advise on whether you have a preferred sandboxing strategy.

[shonfeder]

Should be ready for another look and merge if you're happy with it!

If tests are desired for this, dune cram tests could be a good fix, since all the functionality requires interaction with the OS environment.

[gares]

Now that I think about it twice, I think you should name all sys functions sys.* A proxy can be provided if clients break due to the renaming of getenv, command, gettimeofday. Maybe the latter belongs to unix?

Maybe you can start putting the new code in sys and do the renaming of existing code in another pr.

[gares]

Also, because of another merge, you should re-promote the tests.
It would also be nice to have a few lines in the CHANGES file.

[shonfeder]

Now that I think about it twice, I think you should name all sys functions sys.* A proxy can be provided if clients break due to the renaming of getenv, command, gettimeofday. Maybe the latter belongs to unix?

Maybe you can start putting the new code in sys and do the renaming of existing code in another pr.

I agree that this naming is better! That is actually what I am doing in the project I pulled these from, but I tried to adopt the existing convention here. I've made this change, leaving the existing predicates for a followup PR.

I've also regenerated the fixtures and rebased.