feat: add riscv64 clang build with pointer compression enabled

[sxa]

This serves two purposes:

• Trial clang cross-compile builds (Fixes Move riscv64 cross builds to clang #217) - I've chosen to make this a separate recipe for now so that differences can be noted.
• Add the experimental pointer compression build option which should significantly reduce memory usage (Ref discussion in Add kxxt and luyahan to riscv platform team admin#1042 (comment)).

While I appreciate that this is two changes which could both introduce differences in behavior it seems the best way of having this testable and we can do one-off builds with one or the other as desired (Part of me wanted to skip ICU in this build too in order to reduce memory usage further but I've held off on that for now :-)

Using clang will also be a useful enhancement for Node 26 as all current GCC versions will not build correctly unless -DHWY_BROKEN_EMU128=0 is specified (Ref: nodejs/build#4099 (comment))

FYI @nodejs/platform-riscv64

[sxa]

I've tested this recipe as far as practical on my local machine so it is fundamentally good and able to compile. If reviewers can check there isn't anything completely stupid/missing in here relating to the integration into the unofficial-builds process that would be appreciated. Noting that this could form a template for future clang-based dockerfiles for other experimental platforms.

[sxa]

Also noting that since the clang builds are cross-compilers out of the box, it's possible that we could use a common container for multiple platforms as the only additional requirement for each is the extra package that provides a sysroot, however this approach would require changes to the unofficial-builds workflow so that is not something I'd propose yet.

[rvagg]

I'm fine with you experimenting with this, as long as the experimental recipes are lower in the list and you're keeping an eye on them and their runtime. The current compiles take a long time now, and adding more just extends it even further. When we have multi-line releases come out there's a ton of work to do to get builds out in good time and we have the musl dependency with the Docker builds using our binaries so don't want to be too slow in getting them out.

[sxa]

I'm fine with you experimenting with this, as long as the experimental recipes are lower in the list and you're keeping an eye on them and their runtime. The current compiles take a long time now, and adding more just extends it even further. When we have multi-line releases come out there's a ton of work to do to get builds out in good time and we have the musl dependency with the Docker builds using our binaries so don't want to be too slow in getting them out.

Yep agreed 100%. I'll be using these myself so definitely planning to keep an eye on them, plus the ccache updates from #215 will also make things run through a lot quicker than they have previously (I'd expect that to be especially true for the smaller security updates where release times are more critical and delays really get noticed). As suggested in docker-node#2363 my personal preference would be to remove Alpine (or any other experimental builds) from the docker official image set to avoid people thinking it can be relied upon but that may not be easy ;-) I'm considering having a separate issue in docker-node on that topic so we've at least had the discussion formally and can point people at it.

Having said that now that the governance issues with the docker-node WG are being resolved (something I note you mentioned almost six years ago now!) we could get the PR to decouple Alpine merged as well.