Build with the Python limited API.

[vyasr]

I noticed discussion on #21 around supported Python versions last week and it got me thinking about whether pynvjitlink really needs Python version-specific packages. pynvjitlink uses the C API directly, and it uses a pretty minimal subset, so we can actually just build it with the limited API and get a package compatible across Python versions. I tested the built wheel on 3.11 and 3.12 and tests pass just fine, at least locally.

The main blocker is that we require the limited API as of Python 3.11 (namely support for the buffer protocol) to make this switch. We just dropped support for Python 3.9, so we're likely a year out from dropping 3.10. If we do think that the limited API is a path work exploring, our two options are to simply keep this PR around as a reminder until we drop 3.10, or to bifurcate our build into a 3.10 path and a 3.11+ path. I don't think the latter would be too painful to maintain. It would require three things that I can think of off the top of my head: 1) updating test jobs to download the abi3 wheel for Python>3.11 instead of one specific to their version (so in general, some of the improvements needed for rapidsai/build-planning#43); 2) specifying wheel.py-api via a config-settings flag in build_wheel.sh for Python 3.10; and 3) updating the conda recipes accordingly to set the right run exports for the abi3 packages.

A middle ground might be to do nothing now, but the next time someone asks for support for Python 3.13 we switch to the limited API instead.

Since pynvjitlink has users beyond just RAPIDS, making the change here seems beneficial so that pynvjitlink can uncouple from the Python upgrade cycle of RAPIDS.

[bdice]

I support this conceptually, but there are some other moving parts in the ecosystem. We would need to branch this into 3.10 and 3.11+ wheels. However, by the time we are ready to drop Python 3.10, I expect cuda-python to have nvjitlink bindings. We may have a shorter life for pynvjitlink as a package if we are able to adopt cuda-python's bindings. NVIDIA/cuda-python#98

I am kind of leaning towards keeping things as-is and devoting effort towards adopting cuda-python's bindings once available.

[jakirkham]

Would also note that Python 3.13 with free-threading enabled (so GIL disabled) cannot use the Limited C API or Stable ABI. So there likely will still be special casing with new Python versions

[vyasr]

Yeah I was also thinking about the cuda-python story when I made this. I figured I would open the PR since it was easy to start the discussion, but I'm fine with assuming we'll be moving towards all of the logic eventually going into cuda-python + numba-cuda.