Compute effects for indirect calls in GlobalEffects

[stevenfontanella]

When running in --closed-world, compute effects for indirect calls by unioning the effects of all potential functions of that type. In --closed-world, we assume that all references originate in our module, so the only possible functions that we don't know about are imports. Previously we gave up on effects analysis for indirect calls.

Yields a very small byte count reduction in calcworker (3799354 - 3799297 = 57 bytes). Also shows no significant difference in Binaryen runtime: (0.1346069 -> 0.13375045 = <1% improvement, probably within noise). We expect more benefits after we're able to share indirect call effects with other passes, since currently they're only seen one layer up for callers of functions that indirectly call functions (see the newly-added tests for examples).

Followups:

• Share effect information per type with other passes besides just via Function::effects
• Exclude functions that don't have an address (i.e. functions that aren't the target of ref.func) from effect analysis
• Compute effects more precisely for exact + nullable/non-nullable references

Part of #8615.

[stevenfontanella]

Also added some tests exercising call_indirect.

[stevenfontanella]

Added a test showing two different effect types being aggregated into the same function (global-effects-closed-world-simplify-locals.wast).

[stevenfontanella]

Added a test showing two different effect types being aggregated into the same function (global-effects-closed-world-simplify-locals.wast).

The test went wrong at some point, let me update.

[stevenfontanella]

Added a test showing two different effect types being aggregated into the same function (global-effects-closed-world-simplify-locals.wast).

The test went wrong at some point, let me update.

It turns out that the effects were pessimized when changing the features from --enable-gc --enable-reference-types to -all. Changed the features of the test back and looking into why this is now.

[tlively]

Don't we have to add the function -> function direct call edges whether or not we're in a closed world? I would expect this condition to guard just the early return below.

[stevenfontanella]

We do add these edges in both cases, the code is duplicated below. I wrote it this way since otherwise we'd have to have two different checks for !closedWorld (one continue in the loop and one early return before creating the Type -> Type edges), and I felt that it wasn't clear what the behavior is if !closedWorld since the logic was interleaved.

[stevenfontanella]

Added a test showing two different effect types being aggregated into the same function (global-effects-closed-world-simplify-locals.wast).

The test went wrong at some point, let me update.

It turns out that the effects were pessimized when changing the features from --enable-gc --enable-reference-types to -all. Changed the features of the test back and looking into why this is now.

Looks like this was due to LinearExecutionWalker (used in SimplifyLocals) not taking global effects into account and unconditionally assuming that functions may throw even if we determined that they won't. I tested with #8637 and found that the test works correctly with -all / --enable-exception-handling. Will land that PR after this one.