CodeGen: Be clear about semantics in SlotIndex::getNextSlot(), NFC

CodeGen: Be clear about semantics in SlotIndex::getNextSlot(), NFC

Be honest about using iterator semantics in `SlotIndex::getNextSlot()`
and `SlotIndex::getPrevSlot()`.  Instead of calling `getNextNode()` --
which is documented (but fails) to check for the sentinel -- call
`&*++getIterator()`.

This is (surprisingly!) a NFC commit.  `ilist_traits<IndexListEntry>`
has an `ilist_half_node<IndexListEntry>` as a sentinel (and no other
fields), and so the layout of `ilist<IndexListEntry>` is:
--
struct ilist<IndexListEntry> {
  ilist_half_node<IndexListEntry> Sentinel;
  IndexListEntry *Head;

  IndexListEntry *getHead() { return Head; }
  IndexListEntry *getSentinel() { return cast<...>(&Sentinel); }
};
--
In memory, this happens to look just like:
--
struct ilist<IndexListEntry> {
  ilist_node<IndexListEntry> Sentinel;

  IndexListEntry *getHead() { return Sentinel.getNext(); }
  IndexListEntry *getSentinel() { return cast<...>(&Sentinel); }
};
--
As a result, `ilist_node<IndexListEntry>::getNextNode()` that checks
`getNext()` of the possible sentinel will get a pointer to the head of
the list; it will never detect the sentinel, and will return the
sentinel itself instead of `nullptr` in the special cases.

Since `getNextNode()` and `getPrevNode()` don't work, just be honest
that we're not checking for the end/beginning of the list here.  Since
this code works, I guess we must never go past the sentinel.

(It's possible we're just getting lucky, and the new code will get
"lucky" in the same situations.  To properly fix that hypothetical bug,
we would need to check the iterator against `end()`/`begin()`.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@252538 91177308-0d34-0410-b5e6-96231b3b80d8