Improve coercion dunders

[nicola-bastianello]

as part of #7 I added the coercion dunders __bool__, __int__, __complex__, __index__ alongside __float__ that was already available.

these methods currently do e.g. float(self._backend.squeeze(self).value), but not all frameworks neatly support all coercions (e.g. bool for tf, TypeError: Using a tf.Tensor as a Python bool is not allowed.). this means that we have a dishomogeneous behavior across frameworks

I see two options: 1) we add non-abstract backend methods, like to_float; if a backend does not implement them, we raise a TypeError. 2) we support this in all frameworks (to_float is abstract), and come up with a workaround for frameworks that don't directly allow coercion to scalar

[Simpag]

For methods in the array class that are called infrequently I think its fine if we dispatch it to the iop layer. Performing dtype conversions is not that common during runtime so I think its fine to do so in this case. From a decent-bench perspective, the most costly operations are performed in the cost class and those will be optimized as they usually are native. Other than that, the most costly operations on an Array class level is matmul and normal operations like add, sub, div and mul which currently are optimized.

[nicola-bastianello]

yes, I agree that dispatching to the iop layer will likely be enough for these methods