Revert "[analyzer; alternate edges] improve support for edges with PseudoObjectExprs."

Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).

This reverts r182083, but pieces of it will come back in subsequent commits.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@182185 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Add a debug dump for PathPieces, a list of PathDiagnosticPieces.

Originally implemented by Ted, extended by me.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@182186 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] "Fix" ParentMap to handle non-syntactic OpaqueValueExprs.

Constructs like PseudoObjectExpr, where an expression can appear more than
once in the AST, use OpaqueValueExprs to guard against inadvertent
re-processing of the shared expression during AST traversal. The most
common form of this is to share expressions between the syntactic
"as-written" form of, say, an Objective-C property access 'obj.prop', and
the underlying "semantic" form '[obj prop]'.

However, some constructs can produce OpaqueValueExprs that don't appear in
the syntactic form at all; in these cases the ParentMap wasn't ever traversing
the children of these expressions. This patch fixes that by checking to see
if an OpaqueValueExpr's child has ever been traversed before. There's also a
bit of reset logic when visiting a PseudoObjectExpr to handle the case of
updating the ParentMap, which some external clients depend on.

This still isn't exactly the right fix because we probably want the parent
of the OpaqueValueExpr itself to be its location in the syntactic form if
it's syntactic and the PseudoObjectExpr or BinaryConditionalOperator itself
if it's semantic. Whe I originally wrote the code to do this, I didn't realize
that OpaqueValueExprs themselves are shared in the AST, not just their source
expressions. This patch doesn't change the existing behavior so as not to
break anything inadvertently relying on it; we'll come back to this later.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@182187 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] New edges: include an edge to the end-of-path location.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@182188 91177308-0d34-0410-b5e6-96231b3b80d8