[RUNTIME] Enable NDArray type extension

[tqchen]

This PR proposed an improved version of tvm::NDArray signature that opens the path for future type extensions.

While the current NDArray works great, there is a potential need to extend the NDArray itself to store additional information. This can become useful when we need to introduce variants that might be scheduled by an additional async engine, or a different form of lazy/eager execution.

In these cases, we could potentially subclass the NDArray and NDArray::Container, however, this also brings a potential need for runtime type checking. This PR adds a field array_type_index_ to NDArray::Container to make the structure future compatible with the possibility of extensions. On 64 bit platform, it won't use additional space because we will need an additional int field anyway due to memory alignment issues.

[tqchen]

@junrushao1994 @were @yzhliu @ZihengJiang please review.

[junrushao]

Ok, I see your point. By checking array_type_index_, it is possible for a front end language to understand which subclass the NDArray represents.

[junrushao]

Quick naive questions @tqchen

If an external library wants to inherit tvm arrays, and we don't want to modify TVM's codebase

1. Does it inherit tvm::runtime::NDArray, or tvm::runtime::NDArray::Container, or both? (Looks like it is enough to inherit the container, since NDArray is just a thin layer of the container?)
2. In which part of a frontend should the ext lib inquiry the flag array_type_index_?

[were]

@junrushao1994 I agree with 1 that inheriting the container only will suffice.

If inherit both, maybe they share some attributes, which should be maintained on both sides. This is not good for further maintenance.

If something like an extern::NDArray is desired, a tvm::NDArray can be created and referred by an extern::Container.

The only counter-intuitive part of doing this is that: when garbage collection, tvm::NDArray and tvm::Container free its space when ref_count_ == 1; however, for the extern::NDArray, it should be freed when ref_count_ == 2; at this point, we are going to free the last extern::Container and after that the origin tvm::NDArray can be freed.

[junrushao]

extern::NDArray will be a subclass of tvm::NDArray. extern::NDArray::Container will be a subclass of tvm::NDArray::Container.

I don't understand the ref_count thing. Doesn't seem to be right...

[junrushao]

From the C++ side, if we want TVMArgValue to be able to automatically convert to extern::NDArray, the TVMArgValue probably needs access to array_type_index_.

[junrushao]

Probably we need a method like As<Type>(), in which the tvm::NDArray checks whether Type::array_type_index matches its data_->array_type_index_.

[were]

Here is the situation we are facing:
PackedFunc can only pass TVMArgs-family arguments, like tvm::NDArray.
Thus, an external call will also only get a tvm::NDArray back.
In tvm::NDArray the Container *data_ is protected, so we cannot get data_->array_type_index_.

[were]

To resolve this issue, it will be desirable to have a trait to force users to define a static indicator for each subclass of NDArray and Container, and provide an as<Type>() method to cast it to its corresponding subclass.