[RISCV] Implement "B" bit-manipulation extension and WCH vendor-proprietary "XW" extension

[ArcaneNibble]

This PR implements support for the RISC-V B bit manipulation instructions, which are broken up into Zba, Zbb, and Zbs sub-features.

If acceptable for upstream, it also implements proprietary opcodes from Nanjing Qinheng Microelectronics which are used in their microcontroller products. This is currently not able to be auto-detected from .riscv.attributes and must be manually selected.

Also fixes #7809

[CLAassistant]

All committers have signed the CLA.

[zznop]

I added two follow-up commits on top of the original PR (after rebasing) - they can be found in the test_pr_7859 branch:

1. 9af751ae fixes integration issues from rebasing the PR:

   • Renames the WCH architecture from rv32-wch to rv32gc_wch so it matches the existing RISC-V architecture naming style.
   • Updates the WCH calling convention registration to use the current Rust API closure form.
   • Fixes section-relative ELF relocation symbol lookup by not adding imageBaseAdjustment a second time. This was causing RISC-V PCREL_HI20/LO12 relocation pairs to bind to the wrong local label and produce incorrect relocated ADDI immediates.
     • I would like to see the binary that prompted you to make this change if you can share.

2. 2754c377 updates the new bitmanip lifting to use first-class LLIL operations:

   • Replaces custom/intrinsic lifting for clz, ctz, cpop, and rev8 with LLIL_CLZ, LLIL_CTZ, LLIL_POPCNT, and LLIL_BSWAP.
   • Replaces the branchy max, maxu, min, and minu lifting with LLIL_MAXS, LLIL_MAXU, LLIL_MINS, and LLIL_MINU

I also created two binaries so I could test/observe the lifting output for the new instruction support. The riscv_wch.elf binary must be opened with options to select the rv32gc_wch architecture.

riscv_zba_zbb_zbs.elf.zip
riscv_wch.elf.zip

[zznop]

Your commits (with some changes) have been added in 5.4.10005-dev. Thank you for this awesome PR!

[ArcaneNibble]

fwiw rv32gc_wch would definitely be a bit of a misnomer here. none of these cores support the "D" double-precision floating point extension and thus don't count as implementing "G". the cores typically only implement IMA(F)C