fix: tracing ivy.set_item with Ellipsis/unbound slices

[Sam-Armstrong]

@hmahmood24 just wanted your opinion on this.

The problem is if we trace through the manual set_item logic - _parse_slice/_parse_ellipsis, etc with an Ellipsis or unbounded slice in the query, the indices which get parsed out will then be hard coded into the traced graph. So the traced graph would only work with inputs of the specific shape it was traced with. We can get around this by using numpy as a intermediary step, but this makes the traced graph incompatible with tf.function.

My thought is that we can just use numpy whenever there is an ellipsis or unbounded slice in the query, then at least the traced graph will work when not compiled - this is what I've implemented here. Curious if you agree with my thinking though.

fyi, this issue with dynamic shapes was appearing a lot in the kornia integration testing, which is what brought this issue to light. The changes made here seem to solve most, if not all, the issues.

[hmahmood24]

@Sam-Armstrong I think we moved away from using numpy in set_item and get_item altogether because of it being incompatible with tf.function and was causing tons of issues with native compilations iirc. I'm hesitant to go back to that logic again. Can we implement a partial mixed tensorflow backend impl of set_item which simply does x[query] = val for this particular condition? I think that would work since we enable numpy behaviour in the tensorflow backend and that should also work with tf.function I assume

[Sam-Armstrong]

@hmahmood24 no we can't do that, the experimental numpy behaviour in tensorflow doesn't support mutilation. I've dug into this and I'm pretty sure there's no way around this issue. Either we use numpy (so not tf.function compatible), or we use the manual implementation which will parse this ellipses and slices, but bake the parsed indices into the graph. I thought the condition implemented here was the best trade-off of these two.

[Sam-Armstrong]

merging this as a temporary fix.