Improve type error explanation for partially applied functor

[art-w]

Improve type error explanation for partially applied functor

[gasche]

@Octachron I'm not fond of #12988 as a proposed fix to this issue. My understanding is that when there are several choices that are just as good (from the algorithm's perspective), you tweaked the heuristic on which one to choose to make this specific example work better, at the cost of a degradation in other examples.

My three cents:

1. If there are several optimal edit paths that look very different, should we consider not showing any of them, instead of showing one of them? (maybe sometimes they share a common prefix that they agree on, and we could still show something?) This gets rid of the "some magic is happening to guess one option" feeling that I agree is disturbing.
2. Here my internal algorithm tells me that A_impl is closer to A than to B, so I know that the two edit paths are not equivalent. Could we integrate such metrics in our distance computation? (For example: count the number the disagreeing items as part of the distance between two signatures. Or maybe the proportion of disagreeing items.)
3. @art-w, you are one of the best people around to look at this and have good advice.

[Octachron]

The diffing algorithm is heuristic by nature.
To keep the algorithm efficient we must cut branches early rather than storing all possible possible paths.

Having a finer grained measure of change distance is definitively part on my plans, but our current weight are already underspecified.

Typically, the more principled version of my change would be to make weight dependent on the position in the diffing matrix: the rule for the functor application will be that inserting missing argument is cheaper near end corner of the matrix. But this introduces even more parameters to choose compared to hard-wiring a prefer for path ending with insertion amongst the path with same weight.

[art-w]

I actually like @Octachron fix! Even with a more fancy algorithm that would weight the similarity of the parameters with the expected interfaces, I expect that it would be necessary to break ties in favor of the application order as it produces the least surprising error message (defaulting to "no magic").