ADT: Avoid relying on UB in ilist_node::getNextNode()

ADT: Avoid relying on UB in ilist_node::getNextNode()

Re-implement `ilist_node::getNextNode()` and `getPrevNode()` without
relying on the sentinel having a "next" pointer.  Instead, get access to
the owning list and compare against the `begin()` and `end()` iterators.

This only works when the node *can* get access to the owning list.  The
new support is in `ilist_node_with_parent<>`, and any class `Ty`
inheriting from `ilist_node<NodeTy>` that wants `getNextNode()` and/or
`getPrevNode()` should inherit from
`ilist_node_with_parent<NodeTy, ParentTy>` instead.  The requirements:

  - `NodeTy` must have a `getParent()` function that returns the parent.
  - `ParentTy` must have a `getSublistAccess()` static that, given a(n
    ignored) `NodeTy*` (to determine which list), returns a member field
    pointer to the appropriate `ilist<>`.

This isn't the cleanest way to get access to the owning list, but it
leverages the API already used in the IR hierarchy (see, e.g.,
`Instruction::getSublistAccess()`).

If anyone feels like ripping out the calls to `getNextNode()` and
`getPrevNode()` and replacing with direct iterator logic, they can also
remove the access function, etc., but as an incremental step, I'm
maintaining the API where it's currently used in tree.

If these requirements are *not* met, call sites with access to the ilist
can call `iplist<NodeTy>::getNextNode(NodeTy*)` directly, as in
ilistTest.cpp.

Why rewrite this?

The old code was broken, calling `getNext()` on a sentinel that possibly
didn't have a "next" pointer at all!  The new code avoids that
particular flavour of UB (see the commit message for r252538 for more
details about the "lucky" memory layout that made this function so
interesting).

There's still some UB here: the end iterator gets downcast to `NodeTy*`,
even when it's a sentinel (which is typically
`ilist_half_node<NodeTy*>`).  I'll tackle that in follow-up commits.
See this llvm-dev thread for more details:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html

What's the danger?

There might be some code that relies on `getNextNode()` or
`getPrevNode()` *never* returning `nullptr` -- i.e., that relies on them
being broken when the sentinel is an `ilist_half_node<NodeTy>`.  I tried
to root out those cases with the audits I did leading up to r252380, but
it's possible I missed one or two.  I hope not.

(If (1) you have out-of-tree code, (2) you've reverted r252380
temporarily, and (3) you get some weird crashes with this commit, then I
recommend un-reverting r252380 and auditing the compile errors looking
for "strange" implicit conversions.)

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