[Type Refactor] Merge TType and Tensor instances as a single entity

[karllessard]

This PR introduces some breaking changes related to Tensor and their relationship with the NdArray data structure, in an effort of simplification and standardization.

Instances of TType (e.g. TFloat32, TInt32, etc.) now implements directly Tensor, which has been converted to a non-parameterized interface. This allows direct access to the tensor n-dimensional data space from a tensor instance, without the need to dereference to a second object by calling Tensor.data().

// Before
Tensor<TFloat32> t = TFloat32.vectorOf(0, 1, 2, 3);
TFloat32 data = t.data();
data.getFloat(1); // 1.0f

// Now
TFloat32 t = TFloat32.vectorOf(0, 1, 2, 3);
t.getFloat(1); // 1.0f

An instance of TType can now be passed directly to any method accepting a Tensor in input, e.g. Session.Runner.feed. In addition, it is now possible to cast directly a tensor of an unknown type using standard Java explicit or implicit type casting, instead of the custom method expect.

// Before
Tensor<TFloat32> t = session.run().get(0).expect(TFloat32.DTYPE);

// Now
TFloat32 = (TFloat32)s.run().get(0);

In a nutshell, important and/or breaking changes are:

• Convert Tensor from a parameterized class to an non-parameterized interface
• Implement directly Tensor from TType implementations
• Add a RawTensor implementation of Tensor that takes care, among other things, of wrapping the native handle of the tensor in a protected way
• Drop now obsolete Tensor.data(), Tensor.expect() and Operand.data() methods
• tf.constant(TType) has to be renamed to tf.capture(TType) to avoid conflict with other Constant endpoints (left untouched).
  • In a next PR, the use of tf.capture will also become obsolete by implementing directly Operand from tensors.

CC\ @deansher , @Craigacp , @wmeddie

[Craigacp]

While we're in here, is it worth moving the contents of the types.family package into the types package? It seems strange to me to have the interfaces at a lower level than the concrete implementations.

[Craigacp]

s/capture/copy/ or immutableCopy ? I don't particularly like the name capture here as it doesn't actually change the state of the tensor argument.

[karllessard]

I don't like capture neither. As discussed here, eventually the tensors could be automatically converted to constants so we will not need to call this endpoint anymore. Still, I now think copy do sound more appropriate as well, I'll make the change.

[karllessard]

Ok as copy already exist as another primitive op, I've decided to rename capture by constantOf, as it is close enough to the original constant name and will be easier to find by our users on auto-completion.

[karllessard]

While we're in here, is it worth moving the contents of the types.family package into the types package? It seems strange to me to have the interfaces at a lower level than the concrete implementations.

I'm not opposed to this but let's keep it for another PR, more changes in this package are planned for the refactoring in progress.

[Craigacp]

LGTM