Support `tf.Tensor` construction via `Operation` argument

[khatchad]

The tf.Tensor(op, value_index, dtype) constructor allows creating a tensor handle from an existing operation output. To support shape inference for such tensors, we need to:

1. Identify the operation (or generator) that the op argument corresponds to.
2. Delegate the shape computation to that generator, using the value_index to select the correct output.

This requires the ability to trace the op argument back to its creating logic (e.g., a tf.matmul call) and instantiate the appropriate TensorGenerator.

This task is blocked by #340, which addresses the general mechanism for operations involving calls to other tensor generators.

[khatchad]

Here are some technical details and a proposed strategy for implementing this:

Proposed Strategy: Delegation to Source Generator

The core idea is to treat tf.Tensor(op, ...) as a proxy that delegates shape inference to the logic that originally created the operation/tensor.

1. Trace op to Creation Site:

   • Analyze the op argument's points-to set.
   • For each InstanceKey in the set (which represents the operation or tensor c), identify the allocation site and the CGNode (method execution) where it was created.
   • Trace back to the caller of that node to find the specific SSAInvokeInstruction (e.g., c = tf.matmul(...)) that produced this result.

2. Instantiate Source Generator:

   • Use TensorGeneratorFactory to create a new TensorGenerator instance corresponding to that source instruction (e.g., a MatMul generator).
   • This effectively 're-activates' the logic used to compute the shape for the original operation.

3. Delegate Shape Inference:

   • Call getShapes() on the instantiated source generator.
   • If the operation produces multiple outputs (e.g., tf.split), use the value_index argument from the tf.Tensor constructor to select the correct shape from the results.

Prerequisites & Dependencies

• Aliasing: The analysis must ensure that c.op aliases c (or the underlying operation object). If tensorflow.xml currently models c.op as a separate, empty object, it needs to be updated to ensure the connection to the producer is preserved.
• Issue Track initial tensor shapes and dtypes through variables #340: This approach relies on the ability to handle 'operations calling other generators' or tracking dataflow through intermediate variables/operations, which is the core of issue Track initial tensor shapes and dtypes through variables #340.