feat: weakly define forwarded syscalls

[mkroening]

This PR defines weak symbols for forwarded syscalls. This avoids linker errors when building Hermit without feature = "mman", but still allows not compiling the respective syscalls since they might be unused at runtime.

There are two alternatives to this:

1. In the kernel on not(feature = "mman"), we could provide strong syscall symbols but stub them similar to this PR.
2. The kernel could provide the f symbols corresponding to sys_f directly, completely removing the need for this kind of forwarding.
   This way, we would have linker errors only when applications actually use f, not all the time because some unused newlib symbol uses it.
   Other languages than C benefit from having f semantics available. We currently lie in the libc crate and say that sys_f is just f, but this might actually lead to problems. When third-party crates call accept, for example, and check the return value for -1 as mandated by POSIX, we instead return -errno, which is not what applications expect across all programming languages.

Having thought about this more and having written this down, I now think that option 2 is actually the best one, though it is a bigger decision, and this PR may still prove useful until such a decision is made.

CC: @zyuiop

[zyuiop]

I think option 2 makes the most sense.
I also think that it would actually make sense for all forwarded syscalls.
Is the plan to rename sys_f to f, or to keep both?

[mkroening]

I also think that it would actually make sense for all forwarded syscalls.

Makes sense. I added manual weak symbols for some, but not all, because some feel too fundamental or have no way of signaling failure and no good way for stubbing: alloc and friends, clock_nanosleep, exit, getpagesize, get_processor_count. Does that make sense?

Is the plan to rename sys_f to f, or to keep both?

I think it makes sense to keep sys_f around for backwards compatibility, but also for code that may want to opt-in to receiving the error code directly as a return value instead of via errno.

[mkroening]

It might even make sense to accept this PR and to do both alternatives.

There are static libraries, after all, that depend on many of these functions, even if we exclude them from Newlib, for example, the Rust standard library. Option 1 would help with that once we enable fnctl usage from std, for example.

[zyuiop]

Would it make sense to provide the non-sys_ versions automatically using the macro, then?

[mkroening]

Would it make sense to provide the non-sys_ versions automatically using the macro, then?

If you mean #[hermit_macro::system], then yeah, probably. :D