Refactor CHECK_RANGE to be i18n friendly

[MichaelChirico]

Another part of #6503.

I don't see a way to avoid introducing the new columnDesc() helper + associated "sub-buffer"; but I never liked that we're running snprintf() with two "wasted" inputs when colnum==0 previously anyway.

An approach like snprintf(..., strcat(FMT, colnum==0?_(" (target vector)"):_(" column %d named '%s')")), ...) was attempted, but we get the -Wformat-security issue because the formatting template is no longer a string literal -- it'd have to be "%s (%s)" and then another sub-buffer approach IINM, roughly equivalent to what's done here.

I also tried to only create the column_desc buffer inside columnDesc but that would require returning a pointer to a local variable IINM: https://stackoverflow.com/q/12380758/3576984, hence another static char array. I made it "large" to accommodate wide column names generously.

This refactor also exposed the issue where for an Rcomplex value was being passed to %f; for now I'm just using val.r and punting to follow-up to handle this more "properly": #6531.

I think this is in the same spirit as @aitap's comment: #6503 (comment)

[github-actions]

Generated via commit 7b40653

Download link for the artifact containing the test results: ↓ atime-results.zip

Time taken to finish the standard R installation steps: 3 minutes and 36 seconds

Time taken to run atime::atime_pkg on the tests: 9 minutes and 23 seconds

[aitap]

Sorry about the back and forth between what was originally in the code and a lot of extra strings (and extra work for the translators).

[aitap]

I also tried to only create the column_desc buffer inside columnDesc but that would require returning a pointer to a local variable

The buffer could be declared as static inside columnDesc and thus be guaranteed to live on after the function returns. R's own EncodeChar works in a similar way (except the static part points to a dynamically allocated buffer).

[MichaelChirico]

The buffer could be declared as static inside columnDesc and thus be guaranteed to live on after the function returns.

Nice, done! CMIIW but this is preferable to a malloc() approach which would either need to intentionally leak memory or complicate the CHECK_RANGE()/surrounding logic to ensure the memory is free()'d. The approach here is more like an "intentional leak of a fixed, small amount of memory". The downside is that column names could be arbitrarily long; we might add a check for extremely long names but it seems like overkill until requested by a user.

[MichaelChirico]

Sorry about the back and forth between what was originally in the code and a lot of extra strings (and extra work for the translators).

I think no problem at all! Most of the extra work is copy-pasting and they should all be one-after-the-other in the .po file. I view it as a big plus to translators who are empowered to make much better translations without having to awkwardly kludge their languages to fit what we provide.

If anything the downside is on the code maintainers, but I think it's perfectly manageable.