Object dtype

[Ivorforce]

A Variant dtype NDArray would hold Object instead of floats, ints and whatnot.
For the moment, it would not support any mathematical operations (though they can be added in through the Variant interface).

The main reason to have such a dtype is:

• C++ accelerated Object operations
• ND shape organization and access
• Used in get_attribute and set_attribute API (Functions to create an NDArray from objects' fields / set objects' fields from an NDArray #41)

[Ivorforce]

The 'shared vatensor' way would be to create an "Object" dtype is to have the elements be unique_ptr (or shared_ptr) to virtual structs. The objects would need to implement each of the supported functions on other single-objects, returning a unique_ptr on success, much like how a + b takes in two ints and returns an int.
Unfortunately, this would de-pack the arrays, making it very slow, and still defer all the actual work to the object implementations.

A better way would be to allow NumDot to 'inject' a dtype into vatensor, holding a VariantWrapper, and simply define all the required operations on it statically. Unfortunately, this breaks the 'perfect' separation of the two modules. But it makes a lot more sense for an embedded library, since we don't expect to find objects from other vatensor users in our arrays.

I'm gonna have to think about if there's any other ways.