Fixes #7294 with caveats.

function test1() {
    type stringType1 = "foo" | "bar";
    type stringType2 = "baz" | "bar";
    interface Temp1 {
        getValue(name: stringType1): number;
    }
    interface Temp2 {
        getValue(name: stringType2): string;
    }
    function test(t: Temp1 | Temp2) {
        const z = t.getValue("bar"); // Should be fine
    }
}

The above now has no errors, and z is of type number | string.

The caveats are that only one type in the list of union members is allowed to have overloads, and only one type within the list of union members is allowed to have type parameters. The first is because creating the power set of overloads results in a (long) list of overloads whose ordering is unclear. This is maybe surmountable in the future, but for now this seems like a sane place to stop. The second is because introducing multiple sets of type parameters requires unifying them, as multiple type parameters in the same position likely do not infer well (eg, (arg: A & B & {x: string}) => A | B | {x: string}). Again, with more infrastructure, this is potentially fixable, but for now, this seems like a good stopping point. In the case of a union where either of those things are true, we simply do not create a union signature and fall back to the old behavior of not making a signature at all (and so you'll get the "type has no call or construct signatures" error).

There's one open question here which is contextual typing: In the new test I added, I included one of the motivating examples: using forEach on a union of array types:

function test3(items: string[] | number[]) {
    items.forEach(item => console.log(item));
}

With this change, that is now callable, but the argument to the callback you pass will be implicitly any if defined inline. This is because the argument types are intersected, and the intersection of two signatures currently creates an overload list of signatures. As-is, we have logic that explicitly removes contextual typing from overload lists, so no contextual type is provided. This seems incorrect - I believe fixing this could go in one of two ways:

1. Generate a contextual type from an overload list with similar requirements/caveats that union signature creation has.
2. Generate a combined intersection signature just like we now do for union signatures, rather than an overload set.

Even as-is, this seems like a huge improvement over what we do today; we could also choose to do nothing and require an annotation and still be better off than now. I'd rather we make the usecase work fully without user code changes, but it's still better than what we do in master.

I also have one small TODO I'm still working on (and then writing tests for) which is deriving the names for the amalgamated signature's parameters from the input signatures' parameter names. It's more complex than it was the last time I tried this since we added tuple types - I don't really know how to look up symbol names through the effective argument types which may have been fulfilled by a tuple.