Avoid shipping internal musl headers as part of the sysroot

[sbc100]

It turns out that the files in musl/arch/generic/ and musl/arch/emscripten/ are supposed to me internal headers even though the bits/ subdirectories are public.

This change means that syscall_arch.h is not longer visible outside of the musl build (e.g. when building wasmfs) so I moved the public function declarations to emscripten/syscalls.h.

[kleisauke]

The other.test_standalone_system_headers_st test failure looks real, although the complaint about intptr_t being unknown may also be resolved PR #19559 (I plan to split that PR later today).

BTW, are API-incompatible changes in the emscripten/syscalls.h header permitted? In other words, is this public header intended for use outside of Emscripten?

[sbc100]

The other.test_standalone_system_headers_st test failure looks real, although the complaint about intptr_t being unknown may also be resolved PR #19559 (I plan to split that PR later today).

Fixed.

BTW, are API-incompatible changes in the emscripten/syscalls.h header permitted? In other words, is this public header intended for use outside of Emscripten?

I mean.. we can always make ABI-incompatible changes if we deem it worth it (i.e. the impact is low and the benefit is high).

Hopefully the number of users of syscalls.h will always be low (at least I would hope that is the case).

[kleisauke]

Great!

Hopefully the number of users of syscalls.h will always be low (at least I would hope that is the case).

Indeed. AFAIK, after PR #24655 only libsyscall.js, WasmFS and the weak stub override implementations (i.e. emscripten_syscall_stubs.c and standalone.c) rely on it outside of musl itself.

[kleisauke]

LGTM!