Revisit the handling of jit_options for cuLibraryLoadData

[leofang]

Unfortunately as of today it's not possible to use this feature without also building the bindings from source (#73). Let's just disable this path entirely for the time being.

Originally posted by @leofang in #188 (comment)

[leofang]

I feel this might have overlap with #317. We need to look into this @ksimpson-work.

[ksimpson-work]

I did a little bit of digging and This issue is somewhat perplexing. Currently the avenues for constructing an instance of ObjectCode are via the Linker.Link(), or via Program.compile(). For almost every situation, the jit options are handled by the LinkerOptions or ProgramOptions. The only case I currently see which does not obfuscate the options (and jitting all together) from cuModuleLoad is if someone links a bunch of PTX together and calls get_kernel on the resultant ptx CodeObject. This would trigger a lazy_load_module on the ptx without any particular options. Seeing as GetKernel does not provide an argument for options, this works.

The messy bit is in the _lazy_load_module logic, which does error handling for options which are never passed to it. I think if we agree that get_kernel() is never going to accept an options parameter (I personally think that it should not), then we can get rid of the options handling in lazy_load module since they will always == None. This takes into account an upcoming change (in review) to support Program instances with code_type=='ptx'. This will accept programOptions and use the linker as the backend to jit the ptx into cubin.

Let me know if you see holes in this.

[leofang]

Discussed offline, we agree that ObjectCode should not need to take jit_options; it's the job for Program which is being taken care of in #317. Let's just remove jit_options from ObjectCode constructor, since AFAIK it's not used anywhere.