Sparse tensor data structures

[aestriplex]

This PR implements a first draft of the data structures required to implement sparse tensors support in ACL. Here are three points worth discussing:

1. In the COOTensor and CSRTensor classes, I implemented two different strategies for saving indexes. Specifically, in COO tensors, indexes are saved as std::vector (i.e., not in the same buffer provided by the tensor allocator, which is used by values instead). In CSR tensors, on the other hand, I stored them in the allocator buffer and saved only the corresponding (integer) offsets as class members. The method used in CSR is more efficient when working with the tensor (e.g., in a kernel/operator), so I thought I would extend it to the COO tensor as well. Are there any problems if this approach is too “low level”?
2. The test class should be converted into a Fixture.
3. As Pablo said in his comment on my design document in the mailing list, we need to make sure that the validation of current operators fails when using sparse tensors. A good idea, in my opinion, would be to create a “validate” method in ICpuOperator - and other kind of base operators -, so that it can be called within the validate of classes that implement this interface and do not (yet) support sparse tensors (e.g., CpuGemmConv2d). This method, i.e., not performing the direct check !src->info()->is_sparse(), allows these checks to be extended in the future without having to modify all operators.

[aestriplex]

@morgolock Hi Pablo, this week I am going to continue implementing Transpose operator for both CSR and COO tensor. Are my fixes fine so far? In particular, do you prefer indices to be represented as in CSRTensor (i.e., with allocators) or as in COOTensor (with C++ classes, i.e. std::vector)? Personally, I think the solution with allocators is by far the best in view of the implementation of operators. What do you think about it?