Improve control flow analysis in function expressions

[ahejlsberg]

This PR improves control flow analysis as follows:

• Immediately invoked function expressions (IIFEs) are considered part of the surrounding control flow. Effectively, IIFEs act just like statement blocks for purposes of control flow analysis.
• Type guards for captured const locals are in effect within nested function expressions and arrow functions. Although it is not known when (or even whether) a function expression or arrow function will be invoked, it is known that once proven true a type guard for a captured const local will remain true (because the const local can't be reassigned).

Some examples:

declare function getStringOrNumber(): string | number;

// The type guard for x remains in effect in the arrow function because x is a const local.
// Had x been declared using let or var, the type guard would not be in effect.
function f1() {
    const x = getStringOrNumber();
    if (typeof x === "string") {
        const f = () => x.length;  // Ok
    }
}

// Type guard for x remains in effect in the IIFE.
function f2() {
    let x = getStringOrNumber();
    if (typeof x === "string") {
        let n = function() {
            return x.length;  // Ok
        }();
    }
}

// Type guard for x remains in effect and assignment to y is known to
// have executed before IIFE is invoked.
function f3() {
    let x = getStringOrNumber();
    let y: number;
    if (typeof x === "string") {
        let n = (z => x.length + y + z)(y = 1);
    }
}

Fixes #8381.

[ahejlsberg]

@mhegazy @vladima @rbuckton My latest commit optimizes the critical code paths in the binder for a bind time reduction of about 10%. Specifically, the bindChildren method had gotten really bloated and didn't put getContainerFlags to its proper full use. We'll now completely circumvent the container specific logic when the container flags are zero (which is the common case).

[ahejlsberg]

Turns out there were more opportunities for optimization in the binder. Bind time is now reduced by 25% compared to the original code. Latest gains come from completely circumventing bindChildren for terminal nodes (such as identifiers, literals, and other token nodes). Also, the updateStrictMode function was folded into bindWorker.

[mhegazy]

we already check this in getImmediatelyInvokedFunctionExpression

[ahejlsberg]

Yeah, I'll remove it.

[mhegazy]

👍

[mhegazy]

@vladima and @rbuckton can you take a look.

[rbuckton]

Do you also need to save/restore the currentTrueTarget and currentFalseTarget flow labels here? I see that they are tracked in bindConditionalExpressionFlow and bindPrefixUnaryExpressionFlow, but what happens when one branch of the condition contains an IIFE?

[ahejlsberg]

No, there's no need to save those. They're only used when a conditional operator is immediately contained in a conditional statement, and they're saved and restored at that point.