FunctionReporter handling of R6 class methods

[jayqi]

FunctionReporter does not currently inspect R6 classes for their methods. For packages that lean heavily on R6 classes, this can be a significant part of the function dependency network that is effectively missing.

Note that this is different issue than #14 which is around graphing the inheritance network between classes.

[jayqi]

I'm going to take a crack at this, building off of #120.

[jayqi]

This is pretty tricky. We parse function bodies to get dependencies by chopping things down to symbols (names of objects). There are some problems here that make it hard:

• If a function depends on a method called by an instantiated object, then it's really hard (in some cases, impossible?) to know what class that method belongs to. Especially if a function had the object passed in as an argument.
• If an outer object stores a reference to an internal object, and a method of the outer object calls one of the internal object's methods, it's really hard to know what class the internal object's method belongs to. (This can be seen as a subset of the first case.)

Within one class, I think it should be possible looking for patterns of self$method_name or private$method_name to identify dependencies on other methods from the same class (and like normal functions in the package environment). This gets tricky with inheritance. I think we'll need to search up the inheritance path to link calls to inherited functions to the correct node. Similarly with explicit calls to super$method_name.