Use NonSemantic info and other source debug information to map SPIR-V Validation errors to original source

Producers of SPIR-V can often emit invalid SPIR-V, and sometimes even on purpose (DXC).

During the development of a Compiler outputting SPIR-V bugs will be made, when users file bugreports we often ask for a minimally reproducible example.

Someone without a debug build of said compiler may never see the SPIR-V emitted being fed into SPIR-V Tools, and even if they do they'll have a hard time mapping the line of SPIR-V disassembly and the SSA Result ID that the SPIR-V Validator complains about back to their own source code.

Even for compiler developers this would greatly improve the workflow

I'd propose to use the existing embedded source information and non-semantic information (if the producer emits them) to also display are least the file name, function name and line of the function that generated the offending instructions.

Even better if we could show a range of source lines.

The SPIR-V Visualizer is already able to show the expression trees of operands (and their own trees) involved in an Operation or which produced an SSA ResultID, a full trace of source could be printed, similar to a C++ template instantiation error.