Loosen hardlimit application heuristic slightly

[Keno]

Ordinarily our recursion heuristic looks for recursion of edges, widening types to force convergence if a a recursion of edges is detected. However, under some circumstances (currently - as of #31734 when there are multiple applicable methods), we fall back to simple recursion of methods. This can be quite limiting for packages that have a big central dispatch method (e.g. Diffractor). This attempts to find a middle ground by applying the hardlimit fallback only if the split signatures are not concrete. The kind of case that we want to catch here often arise from signatures with unresolved Vararg (where there's a lot of destructuring methods, but since the size of the vararg is not known, we never terminate) or overly abstract types. I'm hoping this provides a better middle ground tradeoff by still prohibiting those kinds of cases while allowing otherwise very concretely inferred code that just happens to dispatch through a central higher-order method.

[vtjnash]

Hmm, I was pretty sure we had written tests for this case before, but concrete seeming (but erroneous / infinite) signatures are exactly the primary sort of thing this code is supposed to be catching and limiting before they hit runaway.