clang: Upgrade to 18.1.4

[kraj]

• e6c3289804a6 [CMake][Release] Disable PGO (#88465) (#89000)
• 028e425f86cc [MIPS] Fix the opcode of max.fmt and mina.fmt (#85609)
• e3c832b37b0a Fix override keyword being print to the left side
• 1deeee3f5da4 Revert "[Mips] Fix missing sign extension in expansion of sub-word atomic max (#77072)"
• 995539ce05ba [LLD] [COFF] Don't add pseudo relocs for dangling references (#88487)
• db67e6fb9ad1 [libc++] Fix -Wgnu-include-next in stddef.h (#88214)
• 647fbc710840 [SelectionDAG] Prevent combination on inconsistent type in combineCarryDiamond (#84888)
• eaae766a20fd [RISCV] Support rv{32, 64}e in the compiler builtins (#88252)
• c24b41d71f2e github-upload-release.py: Fix bug preventing release creation (#84571)
• c837970dd7e9 [Codegen][X86] Fix /HOTPATCH with clang-cl and inline asm (#87639)
• d0ddcce21d91 [InstSimplify] Make sure the simplified value doesn't generate poison in threadBinOpOverSelect (#87075)
• 4056cc29dfd3 Prepend all library intrinsics with # when building for Arm64EC (#87542)
• 6e071cf30599 [SLP]Fix a crash if the argument of call was affected by minbitwidth analysis.
• d89da2ac8839 [libcxx] coerce formatter precision to int (#87738)
• b6ebea7972cd [SPARC] Implement L and H inline asm argument modifiers (#87259)
• bffecba7ce4c [libc++] Simplify the implementation of (#86843)
• 9899a2d76c8f [lit][ci] Publish lit wheels (#88072)
• 3ceccbdb1995 [clang-format] Correctly annotate braces of empty ctors/dtors (#82097)
• 429d62872525 [Headers] Don't declare unreachable() from stddef.h in C++ (#86748)
• feba8727f805 [ConstantRange] Fix off by 1 bugs in UIToFP and SIToFP handling. (#86041)
• e4259b583c92 [Float2Int] Pre-commit test for SIToFP/UIToFP ConstantRange bug. NFC
• daca56d8e162 Bump version to 18.1.4 (#87715)

---

Contributor checklist

• [x] Changes have been tested
• [x] Signed-off-by is present
• [x] The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)