Fix destructuring control flow analysis

[ahejlsberg]

This PR fixes multiple issues related to control flow analysis of destructuring declarations and assignments. Intuitively, for type checking purposes the following should always be true:

• obj.x is equivalent to obj["x"] (property access vs. element access)
• let { x } = obj is equivalent to let x = obj.x (destructuring declaration)
• { x } = obj is equivalent to x = obj.x (destructuring assignment)

However, there were several situations where this was not the case:

function f1(obj: { a: string | undefined }) {
    if (obj.a) {
        obj = { a: undefined };
        let a1 = obj["a"];  // string (Incorrect)
        let a2 = obj.a;  // string | undefined
    }
}

function f2(obj: [number, string] | null[]) {
    let a0 = obj[0];  // number | null
    let a1 = obj[1];  // string | null
    let [b0, b1] = obj;  // string | number | null (Incorrect)
    ([a0, a1] = obj);  // Error (Incorrect)
    if (obj[0] && obj[1]) {
        let c0 = obj[0];  // number
        let c1 = obj[1];  // string
        let [d0, d1] = obj;  // string | number | null (Incorrect)
        ([c0, c1] = obj); // Error (Incorrect)
    }
}

function f3(obj: { a?: number, b?: string }) {
    if (obj.a && obj.b) {
        let { a, b } = obj;  // number, string
        ({ a, b } = obj);  // Error (Incorrect)
    }
}

function f4() {
    let x: boolean;
    ({ x } = 0);
    ({ ["x"]: x } = 0);
    ({ ["x" + ""]: x } = 0);  // No error (Incorrect)
}

This PR fixes all of the above. The PR changes type checking for destructuring declarations and assignments to consistently use getIndexedAccessType to compute the destructured type and getFlowTypeOfReference on a synthetic element access expression to compute the control flow type. Furthermore, the PR properly unifies all handing of property access expressions (obj.x) and element access expressions (obj["x"]) in control flow analysis, and removes the increasingly convoluted logic we needed to handle binding elements from destructuring declarations and object and array literals from destructuring assignments (they now become synthetic element access expressions).

Fixes #26379.
Fixes #28792.

[weswigham]

This error message change is a regression, I believe. An explicit tuple length error here is quite desirable.

[ahejlsberg]

I think the new error is just as good, if not better, and certainly more consistent. I always found this particular message strange as there isn't actually a tuple being assigned to. If we think it is important, we could instead improve the message we give when accessing an out-of-range tuple element in getIndexedAccessType.

[weswigham]

We explicitly added the tuple length error message to override the message it regressed to. Changing getIndexedAccessType to use it seems kinda appropriate.

[DanielRosenwasser]

I think it would be nice to give a more specific error message if it can still be rewired into getIndexedAccessType:

Tuple type '{0}' of length '{1}' has no element at index '{2}'.

Seems pretty reasonable.

[j-oliveras]

I think, like Daniel, that will be better message to avoid issues like #29058.

[weswigham]

While we're here, we should probably change this to isStringOrNumericLiteralLike so NoSubstitutionTemplateLiterals can act like string literals.

[weswigham]

The results of getAccessedPropertyName need to be more strongly inspected - it seems like the results are normally checked with a truthiness check, which will be incorrect for properties named by the empty string. It also looks like some explicit tuple length errors have been replaced with some worse errors - we probably shouldn't regress there.

[DanielRosenwasser]

Do we really need to export this from the public API?

[weswigham]

While I think the error message could still usage a change, this looks OK.

[ahejlsberg]

@DanielRosenwasser @weswigham Now with new and improved error message.

[ahejlsberg]

@DanielRosenwasser And now with no public API changes.