Expose ObjectCode as public API + prune unnecessary input arguments

[ksimpson-work]

close #194
close #448
close #450

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ksimpson-work]

/ok to test

[ksimpson-work]

/ok to test

[leofang]

/ok to test

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-435/
https://nvidia.github.io/cuda-python/pr-preview/pr-435/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-435/cuda-bindings/
Preview will be ready when the GitHub Pages deployment is complete.

[ksimpson-work]

I think we should invest the time to change the design so that ObjectCode only represents cubins, but I think this change can be standalone thanks to the comment about not passing anything but a cubin when directly constructing an ObjectCode.

My thought for ptx / ltoir / other IRs is that we add two things:

Program.code -> returns the code string (for user and needed by linker )
Program.transpile(target_type) -> for advanced users who want to see the IR. give them a method to get their ptx, but isolate it from compile() which will return an ObjectCode that is necessarily wrapping a cubin

Linker will need some modifications. Something like:

Linker.add_code_object becomes Linker.add_program() - this is to pass IR program
Linker.add_object_code(ObjectCodes*)

[leofang]

We discussed the above comment in an offline meeting. Capturing some thoughts:

• transpile() would still have multiple possible output code types, same as compile() today
• We might want to subclass ObjectCode based on the supported code types in the future (ex: PTXObjectCode, CUBINObjectCode, ...). The offline suggestion to add a new from_cubin() constructor, however, makes it possible to defer this discussion to the future and it can be addressed later in a non-breaking fashion. It's also aligned with other parts of cuda.core design and so it is added in this PR now.
• Whatever API that we come up for wrapping cubins as an ObjectCode, it can also take (in-memory) PTX as valid input due to limitations in driver APIs. There is no programmatic way for us to guard against "misuse" (since the driver considers it a legit use case).

FWIW I think adding ObjectCode.code (instead of Program.code) for retrieving the wrapped content makes a lot of sense. I think not having it was an overlook. Let us add it as part of #370. (ObjectCode does not have .handle, but this is close enough.)

@vzhurba01 since both Keenan and I already touched this PR significantly, please kindly review it.

[leofang]

/ok to test

[vzhurba01]

Small test update needed but all else looks good to me

[leofang]

/ok to test

[leofang]

CI is green!