[llvm] [SPIR-V] Expose an API call to initialize SPIRV target and translate input LLVM IR module to SPIR-V (PR #107216)

[Vyacheslav Levytskyy via llvm-commits]

VyacheslavLevytskyy wrote:

> I'm not super familiar with how 3rd party use LLVM, but AFAIK they do have access to the public LLVM headers no? If that's correct, why not require a struct with the option we need in an already parsed format?
> 
> ```
> struct BuildOptions {
>     CodeGenOptLevel OptLevel;
>     Triple TargetTriple;
>     std::vector<std::string> AllowedExtensions;
>     ...
> };
> SPIRVTranslateModule(Module *M, const BuildOptions& Options, ...)
> ```
> 
> ?
> 
> Duplicating the CLI feels a bit weird IMO

The idea was to introduce a loose coupling between SPIRV BE and its user to achieve mainly two goals: avoid forcing a user to include one more header file that would describe this interface in C++ terms (like `struct BuildOptions` data type), and to allow to move development of SPIRV BE and its user library forward with different speed, meaning lack of synchronization with respect of supported and/or mandatory options. Just as an example, Khronos Translator, as a potential user of this feature, doesn't rely on explicitly defined in a command line target triple but expect it to be defined inside the module, so it would create an inconvenience to require this option. Basically, this feature is exactly what you've mentioned, it's a duplication of CLI for cases when usage of existing CLI tools is a poor choice, meaning to substitute existing integration way of calling `llc` as an external executable. The latter seems like a bad practice, so this PR tries to improve user experience (avoiding issues with performance, debug, profile and so on) by providing a direct API call, leaving the same feeling of loose coupling as in the case of preparing a command line to execute.

https://github.com/llvm/llvm-project/pull/107216