Speed up Constraint Solver's overload resolution (II)

[gusty]

This will speed up to 2x overload resolution in cases like this.

This PR is a follow-up of #1530 where it was discussed that ideally the constraint solution can be committed a bit early.

The problem was that knowing the solution early would make some very exotic cases like this one to fail.

After analyzing the problem I found that cases like that would fail because the first overload that is considered would succeed if the constraint is assumed as solved, when in fact it should fail (false positive).

Assuming that specific constraint solution makes impossible to solve the nested overload resolution called by SolveMemberConstraint which is expected to fail and indeed it fails, but because that result is ignored, it's marked as a false positive and the compilation breaks later by not being able to decide between 2 overloads: the good one and the bad one which is treated as good.

The proposed change adds an internal exception to signal the calling function (in the analysed case it was called from solveTypMeetsTyparConstraints) an unresolved overload and make the whole assumption fail.

The tests I made show no performance degradation but an improvement in some cases, which is logically expected because we will be using a shortcut in some cases.

But the improvement went a bit further since now by signaling an inconsistent case it also discards early some paths and I wouldn't be surprised if it fixes some existing bugs which were consequence of this previously ignored result.

Here's a test I run with the following results:

(* before #1530 *)  val compileTime : float = 20613.1785
(* after #1530 *)   val compileTime : float = 563.0135
(* after this PR *) val compileTime : float = 280.0141

[gusty]

The only test that was failing is the example added by @forki on #1530 which was never finishing to compile before that PR, then after #1530 it fails with "No overloads match".

Now with this PR it will fail with "This value is not a function ..." which could makes sense by reading the code, since it's a () value

So this could be an example of a bug fix mentioned above in my PR description. Before it was considering a false positive which gave more than one valid overload, that's why it was failing with "No overloads match".

[dsyme]

This change looks great. Approved.

[gusty]

@dsyme I found a small issue with this PR but it's fixed now.

The original reasoning was to observe the result only when calling from solveTypMeetsTyparConstraints.

Intuition and extensive testing showed that permitWeakResolution could be used for this purpose however I just came up with a very exotic snippet that will fail.

To avoid that, we need to pass an additional parameter which was my original reasoning, and that's exactly what I did to fix it.

[KevinRansom]

Thank you for taking care of this