Move handling of integer signedness to the backend conversions

[ramiro050]

The function getTypeForScalarType currently takes an argument to specify the signedness of integer types. This is leakage of backend specific requirements into the torch dialect world. Because getTypeForScalarType is a utility function for the torch dialect, it should only produce types that match the sign conventions used by PyTorch (regular integers are signed and unsigned integers are unsigned).

This commit removes the signedness argument from
getTypeForScalarType, and moves the backend specific handling of integer types to the backend code.

[ramiro050]

With this patch, we get the following transformation:

func.func private @forward(%arg0: !torch.vtensor<[20,100,35,45],f32>) -> !torch.vtensor<[20,100,35,45],f32> {
  %int0 = torch.constant.int 0
  %0 = torch.prim.ListConstruct %int0 : (!torch.int) -> !torch.list<int>
  %int0_0 = torch.constant.int 0
  %int0_1 = torch.constant.int 0
  %cpu = torch.constant.device "cpu"
  %none = torch.constant.none
  %none_2 = torch.constant.none
  %1 = torch.aten.empty.memory_format %0, %int0_0, %int0_1, %cpu, %none, %none_2 : !torch.list<int>, !torch.int, !torch.int, !torch.Device, !torch.none, !torch.none -> !torch.vtensor<[0],ui8>
  return %arg0 : !torch.vtensor<[20,100,35,45],f32>
}

// -----// IR Dump After ConvertTorchToLinalg (convert-torch-to-linalg) //----- //
func.func private @forward(%arg0: !torch.vtensor<[20,100,35,45],f32>) -> !torch.vtensor<[20,100,35,45],f32> {
  %int0 = torch.constant.int 0
  %0 = torch.prim.ListConstruct %int0 : (!torch.int) -> !torch.list<int>
  %int0_0 = torch.constant.int 0
  %int0_1 = torch.constant.int 0
  %cpu = torch.constant.device "cpu"
  %none = torch.constant.none
  %none_2 = torch.constant.none
  %1 = torch_c.to_i64 %int0
  %2 = arith.index_cast %1 : i64 to index
  %3 = tensor.empty(%2) : tensor<?xi8>
  %cast = tensor.cast %3 : tensor<?xi8> to tensor<0xi8>
  return %arg0 : !torch.vtensor<[20,100,35,45],f32>
}

[AmosLewis]

LGTM. I also test the iree and shark-turbine where the issue first found, everything looks good now. nod-ai/SHARK-ModelDev#110