refactor(rapids-artifact-name): add explicit --arch flag to override $(arch)

[gforsyth]

• refactor(rapids-artifact-name): add explicit --arch flag to override $(arch)
• Revert "fix(rapids-artifact-name): handling for "true" pure artifacts vs. cuda-dependent pure artifacts (fix(rapids-artifact-name): handling for "true" pure artifacts vs. cuda-dependent pure artifacts #254)"

Sorry for the churn on this.
This PR reverts the change in #254 for a few reasons:

1. I was wrong about the categories of "purity" for artifacts (or not right enough) -- distributed_ucxx has a dependency on cuda version (or is built for both cuda 12 and cuda 13, at least) but is CPU arch independent.
2. My solution for the categories of "purity" made the inclusion of the CPU architecture in the artifact name a side-effect, which is bad.

So, instead, after reverting that change, I'm adding an additional (and
optional) --arch <value> flag, that, if used, overrides the value of
$(arch) with the user-provided string.

This could be useful for downloading artifacts with a different architecture
than the system a developer is currently using, and can also be used to set an
arbitrary value for arch for the cases like distributed_ucxx where we build
on x86_64 but use the artifacts built there on both x64_64 and aarch64
systems. (This is true for anythign that doesn't have compiled code but does have CUDA-version-specific dependencies, like nx-cugraph and cuopt-server)

[jameslamb]

I trust your testing, if this fixes the issues let's merge this.

---

distributed_ucxx has a dependency on cuda version (or is built for both cuda 12 and cuda 13, at least) but is CPU arch independent

This would be true for anything that doesn't have compiled code but does have CUDA-version-specific dependencies. nx-cugraph-{cu12,cu13} and cuopt-server-{cu12,cu13} are other examples.

Everything you said is right, just noting that we're not making changes only for the sake of distributed-ucxx.

[gforsyth]

Everything you said is right, just noting that we're not making changes only for the sake of distributed-ucxx.

Thanks for documenting that, @jameslamb ! Yeah, distributed-ucxx was where I ran into the issues, but it's not a one-off.

As an early open-source collaborator of mine once said, "your special case isn't special enough to allow"

[jameslamb]

Love that haha

[gforsyth]

/merge