Retain literal types in some contextual unions

[weswigham]

Alternative to #18488. Rather than attempt to find a discriminant from the result of a contextual typing pass, this simply retains literal types in unions manufactured during contextual typing of element properties, as the information is still relevant to us there (since we use it for things other than relationship checking - like determining if literal types should be inferred).

Fixes #16457. Handles both cases listed there.

@sandersn I happened to chance upon this while looking at adding more test cases for #17668, before I realized I was about to include a driveby fix for something that there was already a different issue open for. 🐱

[sandersn]

Seems ... OK, if somewhat ad-hoc. @ahejlsberg should take a look at any changes to getUnionType too.

[sandersn]

can you add a method that makes this of the object literal show up in the type baselines? I want to make sure it's not just value: 'done', but value: 'none' | 'done' for the type: 'y' case.

[weswigham]

@sandersn I've added to the test, and added some code to discriminate a contextual this type; the this types within object literals typed by these unions looks much nicer now.

@ahejlsberg I think flagging getUnionType to not remove literal types is probably correct in this specific case - we don't want to lose the information those types provide (namely their literalness).

[weswigham]

@ahejlsberg I've implemented the alternative we just spoke about in person (domain-based literal contextual types and the requisite bidirectional comparable relationship to keep casts functional) on this branch; However there is some fallout that I'm not sold on, for example:

class C<T extends { length: number }> {
        constructor(x: T) { }
        foo<U extends T>(x: U) {
            function bar<V extends U>(x: V) {
                return x;
            }
            return bar;
        }
    }
    
    var c = new C({ length: 2 }); // 2 is now a literal type
    var r = c.foo({ length: 3, charAt: (x: number) => { '' } }); // Making this an error, since `length` is the literal `2`.

While correct in the substitutability of T sense, I'm not sure it matches intent. Is this desirable? Does it warrant re-special-casing type parameters as they were before?

[weswigham]

Based on discussions we've had offline, this is likely superseded by #19587, however I can always reopen this pr if we change our mind.