Fix TopologicalSort for Joint and Cooperative matrices

[MrSidims]

visit method of the sort relies on getNonLiteralOperands method of the
SPIRVType which is being inserted in the module. Without it dependent
types can be inserted in the module in incorrect order.

For example:
TypeCooperativeMatrixKHR %ID%
TypeStruct ... %ID%
is the correct order, but without the patch in some cases the translator
could generate the opposite order.

Signed-off-by: Sidorov, Dmitry [email protected]

[MrSidims]

Honestly this test can be much smaller, like:

  1 ; ModuleID = 'artificial.bc'
  2 target datalayout = "e-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-n8:16:32:64"
  3 target triple = "spir64-unknown-unknown"
  4
  5 %"struct.sycl::_V1::ext::oneapi::experimental::matrix::joint_matrix" = type { target("spirv.CooperativeMatrixKHR", float, 8, 16, 0, 0) }
  6
  7 $matrix_fun = comdat any
  8
  9 ; Function Attrs: convergent norecurse nounwind
 10 define weak_odr dso_local spir_kernel void @matrix_fun() {
 11 entry:
 12   %tC.i = alloca %"struct.sycl::_V1::ext::oneapi::experimental::matrix::joint_matrix"
 13   ret void
 14 }

but since I've removed many matrix test during switch to opaque pointers with an idea to re-generate them later with the appropriate FE, I've decided that may be this patch is a good casus to start doing it :)

and since joint/coop matrix is quite complicated feature it's nice to have real-life IR modules being translated