feat: replace LLVM with C23 intrinsics

[DaniPopes]

Use C23's _BitInt(256), which is more portable than compiling Rust to LLVM textual IR, manually replacing i128 with i256, and compiling it with clang.

[nlordell]

Nice proposal! I really like the suggestion.

Do you know how widely supported _BitInt(256) is? At least with LLVM/Clang on aarch64, it isn't supported:

$ clang -std=c23 main.c -o main.o
main.c:1:21: error: signed _BitInt of bit sizes greater than 128 not supported
    1 | _BitInt(256) square(_BitInt(256) x) {
      |                     ^
main.c:1:1: error: signed _BitInt of bit sizes greater than 128 not supported
    1 | _BitInt(256) square(_BitInt(256) x) {
      | ^
2 errors generated.
$ clang-19 --version
Debian clang version 19.1.7 (++20250114103228+cd708029e0b2-1~exp1~20250114103334.78)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin

[nlordell]

Another option which I would be in favor of would be to not replace LLVM intrinsics, but instead change ethnum-intrinsics to build either with LLVM-IR as it does now or C23 based on a feature flag.

[DaniPopes]

afaict gcc and clang have support for most common architectures, you can use the -fexperimental flag on clang to increase the max width where not supported (see build script)

[sambacha]

the build script for macOS isn't x86 comapt, brew has different paths on that chipset

[nlordell]

Hey, sorry for taking so long to get back to you on this - I couldn't find the time to look into _BitInt properly.

First of all, I think this is a great idea, but there are some issues which make me not want to merge this in its current state:

1. _BitInt is, by the standard, only required to be supported up until ULLONG_WIDTH. This means that _BitInt(256) is not guaranteed to be supported (and in fact, clang doesn't support it on all platforms, even with -fexperimental-max-bitint-width=256; for example, it does not work when targeting wasm32 which I personally use). This means, I would not want to replace LLVM intrinsics but instead provide C intrinsics side-by-side.
2. The PR changes a lot more than just introducing C intrinsics, while some of the cleanups are nice, I do not agree with all of them. Many are are unrelated to the "C intrinsic" topic and I do not want to accept them in the same PR.