Replace XlaValue with upstream lazy::Value

[wonjoo-wj]

Replace XlaValue with upstream lazy::Value

Following up on #3567, we see that keeping our own torch_xla::XlaValue causes issues for LTC codegen and will make things unnecessarily more complicated. This removes our torch_xla::XlaValue completely and uses the upstream lazy::Value.

This PR adds a function GetXlaShape(lazy::Value) in ir.h that retrieves the xla shape given a lazy::Value, which eliminates the need to keep our own XlaValue.

[wonjoo-wj]

Test failing with:

test_memory_format_operators_xla (__main__.TestTorchDeviceTypeXLA) ... 2022-05-17 08:44:27.570902: F     920 tensorflow/compiler/xla/shape_util.cc:802] TUPLE primitive type has no definitive size
*** Received signal 6 ***

*** Begin stack trace ***
	tensorflow::CurrentStackTrace[abi:cxx11]()
	
	
	gsignal
	abort
	
	xla::ShapeUtil::ByteSizeOfPrimitiveType(xla::PrimitiveType)
	torch_xla::XlaHelpers::PromoteType(xla::PrimitiveType, xla::PrimitiveType)
	torch_xla::XlaHelpers::GetPromotedBinaryOpShape(xla::Shape const&, xla::Shape const&)
	torch_xla::operator*(torch::lazy::Value const&, torch::lazy::Value const&)

Looking into it.

[wonjoo-wj]

@JackCaoG, this should be ready for a quick review (although it's very long 😢 ), thanks!

[JackCaoG]

Thanks, I think we can merge this one first given the size of the pr and fix the review comment in the next pr.

[JackCaoG]

In fact I think this can be changed. Since now we also use torch::lazy::Value, we don't need to manually call AddOperand, we can reuse upstream constructor to do that. @wonjoolee95 Can you fix that in a follow up pr?

[JackCaoG]

we can also use upstream OpList I think, no need to redefine it here.

[JackCaoG]

@miladm FYI, this will likely cause a lot of conflicts.

[wonjoo-wj]

Thanks, I think we can merge this one first given the size of the pr and fix the review comment in the next pr.

Thanks for the comments! Created a follow-up PR here #3583. Waiting on the CI to verify the tests.