Introduce support for NonSemantic.Shader.DebugInfo rolling version

[MrSidims]

Per updated https://github.com/KhronosGroup/SPIRV-Registry/blob/main/nonsemantic/NonSemantic.Shader.DebugInfo.asciidoc :
Version Compatibility
Later versions are supersets of earlier versions in the following sense:

New instructions may be added.

• Existing instructions maintain their instruction numbers and operand structure within the version they were defined.
• Adding operands to existing instructions, even as optional trailing operands, constitutes a breaking change and requires a new version. Any added operands must be optional trailing operands.
• Validation rules may become stricter for newly generated code.

However, later versions are NOT required to be semantically compatible:

• The meaning of an instruction and its operands will not change unless an operand, added after the instruction’s initial version, is used. Clarifications to the specification text do not constitute semantic changes.
• Tools consuming debug info at version N should use the semantics defined in version N.
• Tools may choose to support multiple versions or drop support for older versions.
• This allows the specification to evolve and fix problematic patterns without being constrained by full backward compatibility.

This has to be taken into an account. See #3744 (comment)

[bashbaug]

We also need to figure out what to do with the "NonSemantic.Shader.DebugInfo.200" extended instruction set that is currently used by the SPIR-V LLVM translator but that was never formally published. Some options are:

1. We treat it as a special case and version "200" is not interpreted to include all of the functionality in the "1XX" versions. We eventually phase out version "200" and move to rolling "1XX" versions instead. This might take a while, but we aren't rolling new "1XX" versions that quickly, so we probably have some time.
2. We formally publish what we've been calling version "200" as version "200" and roll the version from there. Introduces a discontinuity and appears to move to a newer major version, but maybe that's not the end of the world.
3. We formally publish what we've been calling version "200" as some "1XX" version, say "102", and perform some sort of optional mapping between version "200" and the formally published "1XX" version. This puts us on the rolling releases without introducing a discontinuity. Eventually, when version "200" has phased out and is no longer needed, we can remove support.

Are there other options to consider? Is there a preferred path forward?

[MrSidims]

NonSemantic.Shader.DebugInfo.200

I believe it should be 1XX. Outstanding issues are:

1. What to do with debug array type, which has changed semantics - me read is that re-definition of an instruction in the rolling version is possible, yet not encouraged;
2. What to do with extra source language table - may be just trim it and move to the core spec? Objectively I don't remember anything but Fortran useful in this table.

[bashbaug]

Yeah, I was leaning towards my option (3) - publish what we've been calling "200" as some "1XX" version, then figure out what we need to do in this project to keep compatibility as best we can for compilers generating or consuming the current "200".

Have you started to fold in the previous NonSemantic.Shader.DebugInfo.200 changes into the rolling NonSemantic.Shader.DebugInfo spec? If not, I don't mind taking a first pass at this.

[MrSidims]

I had something started, but it was the easiest part, like adding new debug expressions, trampoline and module instructions and nothing regarding type array handling. I can push it to the registry later today (it's on my personal PC, won't get to it until evening) and add you as collaborator to my Registry fork, so you could take the hardest part :D

[MrSidims]

Actually, the way I added trampoline is not great. Created KhronosGroup/SPIRV-Registry#418 without it, @bashbaug you should be modify the PR as maintainer - if not, I'll add you as contributor as promosed.