add rapids-get-pr-wheel-artifact for quickly downloading cpp wheels

[msarahan]

This idea comes from a slack DM with Viyas:

OK, so the first piece I'm thinking of is artifact download. If you look at the raft PR, we have snippets like this:
artifact_name=$(RAPIDS_PY_WHEEL_NAME="librmm_${RAPIDS_PY_CUDA_SUFFIX}" RAPIDS_REPOSITORY=rmm RAPIDS_PY_VERSION="3.11" rapids-package-name wheel_python)
commit=$(git ls-remote https://github.com/rapidsai/rmm.git refs/heads/pull-request/1512 | cut -c1-7)
librmm_wheelhouse=$(rapids-get-artifact "ci/rmm/pull-request/1512/${commit}/${artifact_name}")

The snippet above demonstrates two issues:
There isn't an easy way to download arbitrary PR wheel artifacts. However, there is such a tool for conda artifacts. That was added in #85. What we want is to generalize this tool to work for wheels.
The librmm wheel should not be specific to a particular Python version because it's a pure C++ wheel. However, our current naming scheme on downloads.rapids.ai doesn't know that. I'm currently hacking it by specifying the RAPIDS_PY_VERSION="3.11". This is working because I'm restricting the C++ wheel build CI job to only run with Python 3.11. There was another recent gha-tools PR that added support for pure Python wheels. What we want is to generalize this tool to also work for C++ wheels. The main difference is that C++ wheels have to care about arch, whereas pure Python wheels do not

I think a good starting point would be to make PRs to gha-tools to address the above issues. Does that make sense?

At the time that I'm submitting this, I haven't yet found examples of the wheels_cpp files. Vyas is working on fleshing those out, and I will be taking over that work from him once he gets it on the right track.

[vyasr]

Note that we may not update every repo that's using these tools to the new wheels strategy, but we will at least have to ensure that we update them for the breaking changes here.

[msarahan]

On second thought, the breaking change here may not be the best approach. I thought it would be a helpful guide for which repos need fixing to add wheel support. If it's going to disrupt things with a lot of repos for no change to those repos, then I think it might be better to preserve the wheel_python default behavior.

Maybe something like:

# default assumes wheel_python. If manually specified, do that instead.
pkg_name="$(rapids-package-name wheel_python)"

if [ "$1" = "cpp" ] || [ "$1" = "python" ]; then
	pkg_type=$1
	pkg_name="$(rapids-package-name "wheel_${pkg_type}")"
	# remove pkg_type from args because we handle it in this script
	shift;
fi

[vyasr]

Yikes I reviewed this a week ago but apparently I never submitted. Sorry about that.

[vyasr]

Another option that would probably be more consistent with other scripts in this repo would be to use an environment variable. I'm not the biggest fan of how much we've proliferated those, and maybe what we really need to start doing is introducing some proper argument parsing (e.g. via getopts), but that's out of scope for this PR (but curious what others like @bdice and @ajschmidt8 think about that).

[bdice]

I'm fine with the code here. We can have a follow-up to clean up all uses of the script so they declare the pkg_type.

[ajschmidt8]

To be honest I'm hoping we can remove a lot of these scripts entirely pending the outcome of https://github.com/rapidsai/ops/issues/2982.

If that issue ends up being rolled out, I think that would be a good time to rethink some of the interfaces for any of the helper scripts that we do keep around.

[bdice]

I'm fine with the code here. We can have a follow-up to clean up all uses of the script so they declare the pkg_type.

[vyasr]

It would also be good to update the docs showing how this works once we finalize and merge this tool.

[ajschmidt8]

No questions/objections from me.

Approved pending the resolution of Brad's questions