This is not something that needs to be intrinsified. Note that compiler
optimizations are still possible and the fact whether 'indices' is a member or
an extension is irrelevant to the optimizer
This doesn't fix anything, just makes it easier to figure out values of what
types are used where. Progression increment is of its own type, which may be
different from asmElementType in case of Byte, Char, Short progressions
#KT-492 Fixed
For Byte, Char and Short ranges, promote the type of the loop parameter to int
to avoid overflows. For Int and Long ranges at the end of the loop over a
progression we now check if the new (incremented) value of the loop parameter
is greater than the old value iff increment > 0
#KT-492 In Progress
For Byte, Char and Short explicit casting from Int is removed -- loop parameter
is already stored in an Int anyway. For Int and Long comparison "i < end" at
the beginning of the loop is replaced to "i != end" at the end of the loop + a
special check for an empty loop
