Step #1 to giving Callgraph some sane invariants. The problems with callgraph

Step #1 to giving Callgraph some sane invariants.  The problems with callgraph
stem from the fact that we have two types of passes that need to update it:

1. callgraphscc and module passes that are explicitly aware of it
2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes
   by the CGSCC Passmgr.

In the case of #1, we can reasonably expect the passes to update the call
graph just like any analysis.  However, functionpasses are not and generally
should not be CG aware.  This has caused us no end of problems, so this takes
a new approach.  Logically, the CGSCC Pass manager can rescan every function
after it runs a function pass over it to see if the functionpass made any
updates to the IR that affect the callgraph.  This allows it to catch new calls
introduced by the functionpass.

In practice, doing this would be slow.  This implementation keeps track of
whether or not the current scc is dirtied by a function pass, and, if so,
delays updating the callgraph until it is actually needed again.  This was
we avoid extraneous rescans, but we still have good invariants when the
callgraph is needed.

Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode
to use a CallBackVH for the callsite entry of the CallGraphNode.  This way
we can immediately remove entries from the callgraph when a FunctionPass is
active instead of having dangling pointers.  The current pass tries to tolerate
these dangling pointers, but it is just an evil hack.

This is related to PR3601/4835/4029.  This also reverts r80541, a hack working
around the sad lack of invariants.

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