improve nongeneric methods of Base.rest

[nsajko]

Allow non-Int in dispatch for the second argument (iteration state), but typeassert Int in the method body. This improves abstract inference because the compiler can know the second argument must be Int to avoid a throw, when previously such a call would have dispatched to the generic method.

[nsajko]

Parts of this PR had been split into PR #60808 and PR #60809 and are now merged. Fixing merge conflicts.

[simeonschaub]

I can see how this could help inference for Base.rest, but in indexed_iterate i is always an Int literal inserted by lowering, are there any realistic use cases where this would matter?

[nsajko]

in indexed_iterate i is always an Int literal inserted by lowering

A JuliaHub search indicates that several packages implement an indexed_iterate method. In some cases indexed_iterate is also called from that method. So if constrop bails, which happens easily in any case, i is not a compile-time constant any more.

While, indexed_iterate is not public from Base, so the packages that use this function are technically buggy, it seems to me it would indeed make sense to make indexed_iterate function a public interface, so packages could implement it for custom collection/iterator types they own in a supported manner.

I believe that justifies this PR. Of course, I could also split the indexed_iterate changes from the rest changes, if the rest changes will be easier to get merged.

[simeonschaub]

So if constrop bails, which happens easily in any case, i is not a compile-time constant any more.

Sure, but it will still be inferred as Int, even without constant propagation. For this PR to be useful, indexed_iterate would have to be called from a context where the index can't even be inferred to be an Int and in such a case you might as well call iterate directly. I don't think we should make this code uglier without any concrete real-world motivation

[DilumAluthge]

CI is all green now. @oscardssmith Do you want to merge this?