Let CallGraph.call_graph_of_define return unprocessed callees

Summary:
For context, later we want the higher order call graph to take a
`DefineCallGraph` (which is the original call graph) and update it (e.g.,
removing the higher order parameters, adding new callees). A `DefineCallGraph`
is not great for modification for the following reasons -- it is currently
intended for query only, not for modification.

First, it is unclear how to properly add new callees for an entry of variant
`Singleton` of a `LocationCallees`, because a `Singleton` does not contain
expression identifiers. We do not know if we want to convert a `Singleton` to a
`Compound` or keep it unchanged, because a `Singleton` does not contain the
expression identifiers.

Second, it is more cumbersome to update a `Map.Tree` than a hash map, since
`Map.Tree` is immutable and requires taking it as an argument and returning it
in order for modification.

Third, it is less performant to update an entry in a `Map.Tree` than a hash
map.

A few other notable changes:
1. Explicate the relation between `LocationCallees` and
`UnprocessedLocationCallees`, by moving module `UnprocessedLocationCallees`
into `LocationCallees`.
2. `unprocessed_call_graph_of_define` and `unprocessed_call_graph_of_callable`
now return a `UnprocessedDefineCallGraph`, so that the result can be used by
`unprocessed_call_graph_of_define`.
3. Create module `MakeResolveCallGraph` to reuse the callee resolution
functions for `UnprocessedDefineCallGraph` and `DefineCallGraph`. The
resolution functions are used inside and outside `callGraph.ml`.

Reviewed By: arthaud

Differential Revision: D65460015

fbshipit-source-id: 7f9904963fbe00aaf33e062667b0a54313be3a66