When faced with a call x.m() where the type of x is some interface I, getACallee() does the conservative thing and resolves the call to all overriding definitions of m.

For the data-flow analysis, we try a bit harder: the viableCallee predicate checks whether it can by local reasoning determine a concrete (non-interface) type for x, or perhaps a set of such types, and then resolves m on those.

This PR adds an orthogonal refinement: even if we can't determine a concrete type for x, we can still require that the overriding definition of m we select must belong to a type that implements I. This isn't a trivial condition, since I might inherit m from another interface J, and this way we might be able to exclude some definitions of m in types that implement J but not I.

Evaluation (internal link) shows no performance change and one alert change. The alert in question had 56 paths; I didn't check all of them, but the ones I did inspect all had a spurious call step of the kind described above in them, so I'm inclined to believe that this was a false positive that is now fixed.

It also fixes a wrong call step observed by @owen-mc, but it does not, by itself, fix the false positive that gave rise to. There is another imprecision involved, which I will fix in a separate PR.

Commit-by-commit review is encouraged. The first commit is not logically related to the rest of the PR, but it's useful for debugging and I've wanted to add it for a while.