Fix -Woverflow warning for POSIX_RLIMIT_INFINITY on 32-bit (arm32)

[marc-mabe]

With a 64-bit rlim_t, RLIM_INFINITY does not fit into a 32-bit zend_long and the implicit conversion warns, which breaks --enable-werror builds. Register -1 in that case, which posix_setrlimit() maps back to RLIM_INFINITY. This is the value the truncation produced already, so the constant does not change on any platform.

[GromNaN]

A test idea would be to add a PHPT that verifies POSIX_RLIMIT_INFINITY is exposed with the expected value and that posix_setrlimit() accepts it without warnings. If the 32-bit warning is hard to reproduce directly in CI, an assertion on the constant value and the round-trip behavior should still cover the regression.

[marc-mabe]

A test idea would be to add a PHPT that verifies POSIX_RLIMIT_INFINITY is exposed with the expected value and that posix_setrlimit() accepts it without warnings. If the 32-bit warning is hard to reproduce directly in CI, an assertion on the constant value and the round-trip behavior should still cover the regression.

This PR is not changing anything except fixing a compiler warning.
RLIM_INFINITY is -1 and on 32-bit with a 64-bit rlim_t (e.g. arm32/glibc) was truncated from -1 (64bit/rlim_t) to -1 (32bit/zend_long). That truncation is what GCC 15 warns about. The constant is -1 before and after this change. C converts a negative value to an unsigned type modulo 2^N (C11 6.3.1.3p2), so a 32-bit -1 becomes 0xFFFFFFFFFFFFFFFF in a 64-bit rlim_t, not 0x00000000FFFFFFFF - everything as before - nothing was wrong.

But you are right - there is no phpt using POSIX_RLIMIT_INFINITY

[marc-mabe]

Now, a small phpt covers POSIX_RLIMIT_INFINITY as well