Rename `nextind`, `prevind` and `thisind` to unabbreviated names

[jakobnissen]

The names of nextind, prevind and thisind are not in line with the rest of Julia's naming conventions.

From the style guide:

conciseness is valued, but avoid abbreviation (indexin rather than indxin) as it becomes difficult to remember whether and how particular words are abbreviated.

Also, the other index operations like firstindex, lastindex, eachindex, getindex, setindex! and checkindex do not use the abbreviated form of "index".

[StefanKarpinski]

This would not happen in any case until Julia 2.0.

[martinholters]

Well, we could add the new names and remove the old ones from the documentation

[JeffBezanson]

I'm ok with this except for the potential previousindex, which is too long and lacks the nice property that next and prev are the same length.

[GregPlowman]

I’ll just state the obvious compromise arising from the prev comment: previndex

[stevengj]

I wish there was a way to make string indexing operations more compact and convenient instead.

How about replacing nextind(s, i) with (s,i)+1 etcetera? (Or maybe something more exotic like s@i + 1, or …?) Or (s,i)++, or i[s]+1 (where i[s] returns a StringIndex object that knows how to increment itself), or…

[StefanKarpinski]

Now that immutable struct with references don't force heap allocation, you could define this:

struct StringIndex{S<:AbstractString}
    string::S
    index::Int
end

Then you could have i = StringIndex(str, ind) and define i + 1 to advance by the right number of bytes in the string that it indexes into. Slightly unclear what we should do if you use a StringIndex to index into a different string, but this scheme would make it much easier to work with string indices. Of course, it's breaking, but you shouldn't generally be doing raw arithmetic on string indices, so that might be fine for 2.0 and not break much.