xm-darwin: force 32-bit HOST_WIDE_INT to match Linux i386 reference

[andreadellacorte]

Problem

The macOS-native cc1 binaries (added in #34) produce non-bit-identical machine code vs the Linux i386 reference build for the same C input. Concrete repro: when used as the cc1 binary for rood-reverse (a PSX decompilation), 8 of the project's PRGs fail `make check`. Same C source, same maspsx/binutils chain, same preprocessor — only the cc1 binary differs.

For example, MENU8.PRG/88.o is 44 bytes shorter when compiled by the macOS cc1 vs the Linux cc1, and that drift cascades across sections downstream.

Root cause

`machmode.h:49-55` derives `HOST_WIDE_INT` from `long`:

```c
#if HOST_BITS_PER_LONG > HOST_BITS_PER_INT
#define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG
#define HOST_WIDE_INT long
#else
#define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_INT
#define HOST_WIDE_INT int
#endif
```

• Linux build: `--host=i386-pc-linux` + `CFLAGS="-m32 -static"` → LONG=32, INT=32 → `HOST_WIDE_INT = int` (32-bit)
• macOS build: LP64 → LONG=64, INT=32 → `HOST_WIDE_INT = long` (64-bit)

cc1's internal integer-constant arithmetic (constant folding, RTL constants, shifts, sign-extension) all operate on `HOST_WIDE_INT`. With 64-bit width, intermediate values keep precision the source never asked for, propagating into different code generation in non-trivial ways.

Fix

Override `HOST_WIDE_INT` to 32-bit in `patches/xm-darwin.h`. cc1 itself remains a 64-bit Mach-O binary; only target-constant width is constrained. Host pointer / `size_t` semantics are unaffected.

Test

Adds `tests/host_wide_int.c` — compiles `return 1u << 31;` and greps for `# 0x80000000$` in the output. cc1 prints constants at `HOST_WIDE_INT` width:

• 32-bit (correct): `li $2,-2147483648 # 0x80000000`
• 64-bit (broken): `li $2,-2147483648 # 0xffffffff80000000`

The grep catches the divergence without needing bit-exact .o comparisons. Wired into all three `*-macos.sh` scripts and the corresponding Linux Dockerfiles for parity.

Validation

With this patch applied:

• All three macOS cc1 binaries (2.7.2-psx, 2.7.2-cdk, 2.8.1-psx) pass the new test
• Existing `little_endian` / `section_attribute` / `-msoft-float` / etc. tests still pass
• rood-reverse `make check` goes from 8 PRG mismatches to ✔ all match on aarch64-darwin

[Xeeynamo]

Looks good so far. I only ask to remove the comment that have been added. A git blame on file and line is enough to go back to the PR and find the intention of a change.