LLD emits invalid `.hash` section for s390x

```console
❯ cat shared.c
int foo() { return 42; }
❯ clang --target=s390x-linux-gnu -shared -Wl,--hash-style=sysv shared.c
❯ objdump -s -j .hash a.out

a.out: file format elf64-s390

Contents of section .hash:
01b8 00000000 00000003 00000000 00000007 ................
01c8 00000000 00000005 00000000 00000006 ................
01d8 00000000 00000002 00000000 00000000 ................
01e8 00000000 00000000 00000000 00000000 ................
01f8 00000000 00000000 00000000 00000000 ................
0208 00000000 00000004 00000000 00000003 ................

❯ clang --target=s390x-linux-gnu -shared -Wl,--hash-style=sysv shared.c -fuse-ld=lld
❯ objdump -s -j .hash a.out

a.out: file format elf64-s390

Contents of section .hash:
0354 00000006 00000006 00000000 00000003 ................
0364 00000000 00000005 00000000 00000004 ................
0374 00000000 00000000 00000000 00000002 ................
0384 00000000 00000001 ........
```

The disagreement stems from s390x using `Elf64_Xword` for hash table integers, unlike other architectures. (See §3.2.5 in https://github.com/IBM/s390x-abi/releases/download/v1.7/lzsabi_s390x.pdf.)

Reproduce the issue with the two clang commands in the report and inspect LLD's s390x ELF hash-table emission. Consult section 3.2.5 of the linked s390x ABI for the required integer widths, then compare the generated .hash contents with the reference linker output. Done means LLD emits a valid s390x .hash section.

Written by the indexing model from the issue text.