How Do You Solve a Problem Like MSL?

@HansKristian-Work [raises valid concerns](https://github.com/KhronosGroup/SPIRV-Cross/pull/2204#issuecomment-1814542174) about MSL source being sufficiently different in structure and limitations, when compared to the other source backends. This is exacerbated because real-world runtime client apps such as MoltenVK specialize the way they interface with MSL in order to accomplish non-Metal functionality driven by outside needs.

I'm opening this issue up as a forum to discuss how best to handle this.

1. @HansKristian-Work has [suggested](https://github.com/KhronosGroup/SPIRV-Cross/pull/2204#issuecomment-1814621022) that it might be time to separate MSL from SPIRV-Cross. We can discuss how this might work. Is there any need to maintain compatibility with other backends, or should MSL just be separated into a different repo, in a way that it can leverage SPIRV-Cross to date, but the entire repository can evolve only to support MSL, without worrying about how changes might affect other backends?

2. Can we refactor MSL generation to allow specialized functions to be output the handle much of the MSL differences? These functions in turn, might be managed in a SPIRV-branch, or separate repo.

4. With the latest version, Metal is starting to open up to allow runtime functionality to [load and compile Metal LLVM IR code](https://developer.apple.com/metal/shader-converter/), which possibly opens up the idea of compiling from SPIR-V to Metal IR format directly, in a completely separate code conversion library. Doing so would bypass the need to generate and compile MSL source code, which might streamline code generation logic and runtime performance. The missing ingredient to this would be reverse-engineering Metal's specific LLVM IR representation in order to generate that IR code.

This issue names no source files, tests, or entry points. Start with PR #2204 and the linked discussion, then compare the proposed options: separating MSL, refactoring generation, or targeting Metal IR. Done would require a decided direction and an explicitly scoped implementation plan, which the issue does not currently provide.

Written by the indexing model from the issue text.