Our recusion heuristic works by detection recursion of edges of
methods (N.B.: Methods, not specializations). This works reasonably
well, but there are some pathological cases that defeat it. One
common one is to have a wrapper function that calls an internal
function, e.g.

```
mymap(f, x) = _mymap(f, x)
```

If a higher order function is written with such a pattern, it is
quite easy to run into the recursion limit even in legitimate cases.
For example, with the above definition, a fuction like:

```
f(x) = mymap(x) do t
mymap(sin, t)
end
```

will fail to get precise inference. There's various other patterns
that cause similar issues, e.g. optional arguments and keyword arguments
and is one of the more common causes of inference suboptimalities.

This PR attempts to relax this criterion significantly. It is still
based on methods, but considers the entire recursion path rather
than just a single edge. So for example, in our current heuristic,
we would limit:

    E -> A -> B -> C -> A -> B

immediately, but with the proposed heuristic we would not limit it
until we reach:

    E -> A -> B -> C -> A -> B -> C

And in particular, we would not limit

    E -> A -> B -> C -> A -> B -> D -> A -> B -> E

even though the `A->B` edge repeats frequently. This is intentional
to allow code that has a central dispatch function (e.g. Diffractor
has code patterns like that).

If this turns out to be not aggressive enough, we could consider
imposing additional limitations on the intermediate edges, but I
think this is worth a try.