Reverse translation of arithmetic instructions for cooperative matrixes

[vmaksimo]

Implement translation via SPIR-V friendly calls, as:

1. the LLVM instructions are not capable to accept target extension types;
2. matrix arithmetic instructions require additional carry additional rules, which LLVM can not perform (for example while technically Add for vectors and (flattened) matrices is the same - yet for matrices we need to perform extra checks, also mul instruction is complitely different).

As for now some BE would need to recognize and define what to do with a call to __spirv_FMul(matrixA, matrixB). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.

[vmaksimo]

Please take a look @MrSidims @asudarsa @LU-JOHN

[MrSidims]

LGTM, but I will discuss it in the call a bit today.

[MrSidims]

Implement translation via SPIR-V friendly calls, as the LLVM instructions are not capable to accept target extension types.

While it's true - this justification is a bit incorrect. It should be an example, like SPIR-V FMul is being mapped in LLVM for fmul, but matrix multiplication carries special rules, that LLVM can not handle.

LangRef also says, that:
The two arguments to the ‘fmul’ instruction must be [floating-point](https://llvm.org/docs/LangRef.html#t-floating) or [vector](https://llvm.org/docs/LangRef.html#t-vector) of floating-point values. Both arguments must have identical types.

and we technically could represent matrices as vectors, but this wouldn't make fmul working correct and we kinda need new intrinsic functions, but that is another story.