Fix manylinux1 build: O_CLOEXEC fallback in getauxval shim (#3268)

### Description of changes:
The `/proc/self/auxv` fallback added in #3250 unconditionally references
`O_CLOEXEC`, which breaks the build on manylinux1 (CentOS 5, glibc 2.5).
`O_CLOEXEC` was introduced in Linux 2.6.23 / glibc 2.7 (Oct 2007), so
it's absent from manylinux1's `<fcntl.h>`.

Defining `O_CLOEXEC` to `0` when not provided is sufficient. In this
fallback path the fd is opened, read, and closed synchronously inside
`getauxval()` with no intervening `fork()`, so the close-on-exec
semantics aren't security-relevant here — it's purely a syntactic
dependency.

### Call-outs:
manylinux1 is exactly the environment that should land on this fallback
path: it doesn't ship `<sys/auxv.h>`, so `__has_include` correctly
steers it into the `/proc/self/auxv` reader. The bug is just that the
reader itself wasn't quite portable enough.

### Testing:
Existing CI exercises both code paths via
`OPENSSL_GETAUXVAL_FORCE_PROC_FALLBACK`. Locally verified that the
fallback compiles cleanly with `O_CLOEXEC` undefined (simulating the
manylinux1 condition).


By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.

Author: justsmth

crypto/fipsmodule/cpucap/cpu_getauxval_linux.h

@@ -51,6 +51,14 @@
 #include <fcntl.h>
 #include <unistd.h>
 
+// O_CLOEXEC was added in Linux 2.6.23 / glibc 2.7. Older toolchains (e.g.
+// manylinux1 / CentOS 5 with glibc 2.5) do not define it. Fall back to 0;
+// the fd is opened, read, and closed synchronously within this function
+// (no intervening fork), so close-on-exec is not security-relevant here.
+#if !defined(O_CLOEXEC)
+#define O_CLOEXEC 0
+#endif
+
 // Auxiliary vector type constants from the Linux kernel ABI
 // (include/uapi/linux/auxvec.h). The specific values used here are stable.
 #if !defined(AT_NULL)