Improve EPC for unions with multiple discriminants

[jack-williams]

Fixes #32657

Q: Do I need to explicitly coerce map keys to string like: candidates.set("" + type.id, 1);?

[weswigham]

A: yes.

[weswigham]

A comment explaining what criteria this is filtering/selecting on would be useful. I think it's that it returns the first type which matches all discriminant properties (out of multiple which may match), but some text expressing that would be nice.

[jack-williams]

Will do. If there are multiple valid matches it fails rather than picking the first. I did this to avoid situations where the order of the union influenced whether you got an error, sometimes incorrectly. (I think it was a case where some constituents were technically subtypes of another, but the union was unreduced).

[jack-williams]

@weswigham Done. In the case where there are multiple candidates we could return a new union of just those candidates, but I'm not sure of the error message and perf consequences---if you want me to experiment with that approach let me know.

[jack-williams]

A: yes.

Thanks.

What I've written feels kind of messy and could be cleaned up, but I hope the algorithm is on the right lines.

[sandersn]

Sooooo, I also fixed this bug yesterday, in a different PR, while working on a different bug. The algorithms are almost the same, but I feel like my solution is easier to read:

1. It has fewer moving parts -- no matchedProperties counter with associated post-loop retrieval.
2. Instead it uses indices into target.types, so it can use indexOf to retrieve match(es) instead of Array.forEach.

@jack-williams would you mind taking a look?
#32755

I'll merge your commit in order to get your test and make sure you get attribution for this fix as well.

(Thanks @weswigham for pointing this out to me.)