hal: print 64-bit values and pointers without long long casts

[grandixximo]

hal: drop the remaining long long print casts

Requested by @BsAtHome in #4614: "move it all to libfmt and lets be done with it (in a separate PR)". This is that PR, for the sites #4614 did not cover.

hal64 made hal_sint/hal_uint values int64_t and the query function pointers rtapi_intptr_t, but the print sites force-match them with (long long) casts and %lld/%llx. The casts are correct but ugly, and they hide what the actual types are.

Replace with the inttypes.h macros that match the real types: PRId64/PRIu64 for sint/uint (halsh, halmeter, sampler_usr), PRIxPTR for the function pointers (halcmd show funct). Format and argument then agree on both LP64 and ILP32 with no cast. Where fmt fits it is already used (#4614 covers the halcmd thread print); these sites are C files or pointer prints, where the PRI macros are the idiomatic spelling.

Also fixes a real signedness bug in passing: the hm2_eth debug time prints used %llu for signed long long values.

Left alone on purpose: halmodule.cc, where PyErr_Format is Python's own printf and needs its %lld cast, and rtapi_get_time() callers, whose values genuinely are long long so %lld is the correct specifier. Making those fixed-width too is an rtapi API change, separate discussion.

Verified: full build on i386 (Debian trixie container) shows no errors from these files, and on LP64 the macros expand to the same specifier+type combination the casts produced, so output is unchanged.

[BsAtHome]

Using PRId64/PRIu64 and friends is just as or even uglier. We need to drop 32-but compat.

[grandixximo]

Dropping 32-bit compat is a packaging decision, not a code style one, and we have not made it: linuxcnc-uspace ships armhf and i386 binaries in both trixie and sid today, because debian/control says Architecture: any and the buildds build every release arch. An armhf FTBFS is a release-critical bug. If the project decides to drop 32-bit, the correct mechanism is restricting Architecture: in debian/control, not writing format strings that are wrong on the arches we still ship.

Until that decision is made, PRI macros are not compat cruft, they are the only correct C99 spelling for printing int64_t in C. %lld+cast says the same thing with an extra lie in the middle; %ld is wrong on ILP32 and LLP64. In C++ I agree fmt is better, and that is what #4614 uses in halcmd. These files are C.

[BsAtHome]

Dropping 32-bit compat is a packaging decision

The fact that we do not test in CI should say it all IMO. If we tested strictly, then it would fail to build. So why exactly are we distributing something we do not test in CI?

[grandixximo]

That's a great question, which I don't know the answer to :-)
I do know there is an i386 and an armhf package on debian, my guess, Architecture: in debian/control was missed when the decision was made to not build in CI, this time we could do it properly and drop support there as well, that should close it.

[grandixximo]

At the meeting it was decided to keep support for 32bit cause of beaglebone, probably keeping support till 2030 as armhf is going to be supported by debian and kernel till then, since we are close to a release this should go in, different reservations can be discussed next meeting, or here.