Support destructuring in for-in

[Andarist]

closes #3715

Why I'm doing this:

1. destructuring string is already supported in different contexts (TS playground) so it should also be allowed here for consistency
2. the current es5 output is incorrect and can lead to a runtime crash if somebody ignores the fact that typechecking fails and grabs the emitted output. The current output looks like this: for (var first = (void 0)[0] in { test: 1 }) { }. As we can see, we end up with undefined[0] here

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[Andarist]

this was redundant - this call is a mutation and the same call is already done when assigning to forStatement

[Andarist]

I'm not sure if this should actually be using getIndexTypeOrString(rightType). I used it because the branch below this uses that but because it does use it this code typechecks but, IMHO, it shouldn't (TS playground):

function test(obj: { a: 1; b: 2 }) {
  let key: "a" | "b";
  for (key in obj) {
  }
}

[Andarist]

Created this PR to address/discuss this: #54856

[rbuckton]

We don't often make guarantees about the viability of the output when there are errors during the build. I'm also not entirely certain why anyone would want this? Object destructuring in for..in is somewhat pointless, though I could maybe see a justification for for (const [...codePoints] in obj), though I don't think that comes up that often, if at all.

[jakebailey]

To be clear, my understanding is that this PR addresses a followup problem noted in: https://github.com/microsoft/TypeScript/pull/54801/files#r1244316943

[Andarist]

The main motivation behind the PR is that:

destructuring string is already supported in different contexts (TS playground) so it should also be allowed here for consistency

So it's not exactly that I want this - I just find it weird that it's not supported here. It feels inconsistent with other parts of the checker.

We don't often make guarantees about the viability of the output when there are errors during the build.

Sure, I can certainly see that not being a strong argument - this was just added as an extra benefit of this change. On principle, I'd expect a semantically equivalent output (or smth close to that) when down-leveling syntax. The cost of this change isn't exceptionally high and I think that the added correctness/coverage/consistency is worth it.