This was a good time to do this, so we don't have 2 different ways of doing the
same thing.
I needed to do this to figure out if we should expose
`API::moduleImport("flask").getMember("request")` in a helper predicate or
not. I think I ended up using more refenreces to this in the end. Although it's
not unreasonable to let someone do this themselves, I also think it's reasonable
that we provide a helper predicate for this.
This makes collecting metrics on framework coverage a bit simpler (specifically
giving the RoutedParameter class a more descriptive result for getSourceType).
I guess it can also help a bit when trying to get an overview of a new DB, but
making metrics collection easier is my main motivation for this.
This fixes some spurious results that occurred when we considered
_any_ use of `request.something` to be a source, even ones we had
tracked into other functions. To prevent this, using
`getAnImmediateUse` better captures the fact that we want the source
to be just the actual attribute access.
At this point, we may want to reconsider whether we really want the
deeply-nested module structure we had before (and which made the type
trackers somewhat bearable).
There's also a question of how we can make this a bit more
smooth. I think we need to consider exactly how we would like the
interface to this to work.
This is not strictly necessary, but it was bothering me that this
simply covered _all_ nodes that were both definitions and names at the
same time. Now it actually encompasses what the documentation claims
it does.
This is slightly dubious, and should really be in the currently
unimplemented "def" counterpart to the "use" bits we already have.
However, it seems to work correctly, and in the spirit of moving
things along, this seemed like the easier solution. We can always
replace the implementation with the "proper" approach at a later point.
Most of the type trackers in this model were easily replaceable with
uses of the API graph, but the ones for tracking subclasses are
problematic, as these take us out of the API graph.
In lieu of removing the offending flow (which would likely have
consequences for a lot of other tests), I opted to simply _include_
the relevant nodes directly.
