Expose `ObjectCode` as public API

[leofang]

In recent design/impl discussions it became gradually clear to us that we want to separate JIT'ing from loading. This is also the general trend we have seen over the years (ex: why nvPTXCompiler becomes a standalone library). So:

• Program for JIT’ing everything (PTX, NVVM, C++, Tile IR, …)
• ObjectCode for loading

Here comes the catch. The only thing that can be loaded without JIT'ing is a cubin (which was the use case that exposed the bug #448). We need to ensure Program can JIT code either on disk or in memory.

[leofang]

@ksimpson-work does this capture our discussions accurately?

[ksimpson-work]

Yes I think this captures the issue well. Can you clarify on disk vs in memory in this context? Host / device? The solution is not obvious to me. There's a lot to consider!

[leofang]

It is not that complicated at all, it is really just the handling of cuLibraryLoadData (in memory) vs cuLibraryLoadFromFile (on disk), plus their CUfunction counterparts. We already have the code ready and we just need to fix #448.

[ksimpson-work]

I mean specifically with respect to how we handle jit options. #435 #194. I almost wonder if PTX should be a supported code type of ObjectCode since it's not really an object code. Program.Compile('ptx') could return a new Program instance with code_type =='ptx'.