Consider removing special checks for specialized signatures with other overloads

[DanielRosenwasser]

Specialized signatures needing to be compatible with an overload was an artificial requirement due to issues in #943. Now that we've fixed that, we should consider what we're going to do with this rule.

Could we remove it wholesale? That would potentially be a breaking change, but it seems like good one. Basically, the situations you'd run into this would be where you have something like the following...

function doThing(x: "dog"): Dog;
function doThing(x: "cat"): Cat;
function doThing(x: string): Animal;
function doThing(x: string, y?: string): Moose {
}

Where now we'd check if the implementation was assignable to the specialized signatures and give an error. That seems like a good change.

[weswigham]

Given that we know recognize string types wholesale across the typesystem, would it be possible to just remove the concept of 'specialized signatures' entirely (since most of the logic should be handled by normal overload resolution)? I'd love to see Signature.hasStringLiterals go away.

[DanielRosenwasser]

The problem is that specialized signatures are bubbled up to the top of the signature list because of the rule I want to get rid of here. Here's a basic example:

interface I {
    m(x: "ugh"): boolean;
}

interface I {
    m(x: "hello"): string;
    m(x: "world"): number;
    m(x: string): any;
}

With this ordering of interfaces, the signatures will be ordered as

m(x: "hello"): string;
m(x: "world"): number;
m(x: string): any;
m(x: "ugh"): boolean;

Without bubbling specialized signatures at the top during overload resolution, a call to m with "ugh" will never return type boolean. You'll always get any.