Refactor signature relatability

[DanielRosenwasser]

This PR is an attempt to remove duplicated code brought in by #6075.

It is still a work in progress, since there has been a small regression in error reporting.

@sandersn and @JsonFreeman, you two might want to take a look.

[sandersn]

Isn't it a regression to drop these lines?

[DanielRosenwasser]

Yup. I've noted that elsewhere in the PR. Mostly I'm trying to see whether this is an appropriate direction to move in. I need to figure out how to maintain this.

[JsonFreeman]

Are these losses primarily because of the covariant / contravariant reversal, or something else in the change? It might be good to swap them back, just to see if it makes the errors go away.

[DanielRosenwasser]

I tried reverting the order of source/target on parameters to recover the lost error elaborations. Unfortunately, that introduces a bug in which for the following:

function foo<T extends "foo">(f: (x: T) => T) {
    return f;
}

let f = foo((y: "foo" | "bar") => y === "foo" ? y : "foo")

We report

    let f = foo((y: "foo" | "bar") => y === "foo" ? y : "foo");
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!!! error TS2345: Argument of type '(y: "foo" | "bar") => string' is not assignable to parameter of type '(x: "foo") => "foo"'.
!!! error TS2345:   Type 'string' is not assignable to type '"foo"'.
!!! error TS2345:     Type '"foo" | "bar"' is not assignable to type '"foo"'.
!!! error TS2345:       Type '"bar"' is not assignable to type '"foo"'.

Which is

1. An elaboration of the source parameter type being unassignable to the target one (see the bottom two messages)
2. An elaboration on the source return type being unassignable to that of the target. This is because compareTypes succeeded in assignability of the target parameter type to the source parameter type, and we're still using the same elaboration stack.

I'd rather not introduce a callback to revert the elaboration stack between calls to compareTypes, so I think I'm going to try to find a way to make the current code work.

[DanielRosenwasser]

Hey @sandersn and @JsonFreeman any other feedback? I think I've improved error baselines by elaborating in most cases except for primitives. I've also simplified the code by eliminating that elaborateErrors variable.

[sandersn]

The primitive baselines seem good to simplify, but what about these? Is it OK to drop these elaborations?

[sandersn]

Never mind, maybe I shouldn't be reviewing code while I'm sick. I didn't see that it's an insertion not a deletion.

[sandersn]

Looks good to me. But as I said, I'm sick, so make sure @JsonFreeman or future-me (the not-sick one) okays it too.

[RyanCavanaugh]

Reviewed the error baselines in detail and it's a great improvement. I'm not as familiar with this part of the signature checking code so I'd defer to someone else on that front -- there was nothing obvious wrong about it, though.