Unwrap substitutions on conditional check types before comparing them

[weswigham]

Fixes #43123

The outer conditional was creating a substitution on [0], making it look like [0] & [0, any?] at the inner conditional, which 1. didn't unwrap right (since we determine syntactically that we should be able to unwrap the tuple types made), and 2. produces a subtype of what the user actually wrote for the check type, which can alter results unexpectedly. By unwrapping substitutions at check type positions, we avoid this issue.

[andrewbranch]

1. didn't unwrap right (since we determine syntactically that we should be able to unwrap the tuple types made), and 2. produces a subtype of what the user actually wrote for the check type

I’m assuming it was (1) that made the inner conditional evaluate to false? If we are going from substitution types to their actual type in the check type position, won’t that potentially start making a lot more conditional types evaluate to false? I can’t come up with a compelling example (I mean, even the repro in the bug report is reduced to something totally theoretical, not practical), so I might be thinking about this wrong.