perf: avoid O(N^2) exiting-branch checks in CodeFolding

[Changqing-JING]

Follow up PR of #8586 to optimize CodeFolding

optimizeTerminatingTails calls EffectAnalyzer per tail item, each walking the full subtree. On deeply nested blocks this is O(N^2).

Replace the per-item walks with a single O(N) bottom-up PostWalker (populateExitingBranchCache) that pre-computes exiting-branch results for every node, making subsequent lookups O(1).

Example: AssemblyScript GC compiles __visit_members as a br_table dispatch over all types, producing ~N nested blocks with ~N tails. The old code walks each tail's subtree separately -- O(N^2) total node visits. With this change, one bottom-up walk covers all nodes, then each tail lookup is O(1).

(block $A          ;; depth 4000
  (block $B        ;; depth 3999
    (block $C      ;; depth 3998
      ...
      (br_table $A $B $C ... (local.get $rtid))
    )
    (unreachable)  ;; tail at depth 3999, old code walks 3999 nodes
  )
  (unreachable)    ;; tail at depth 4000, old code walks 4000 nodes
)

benchmark data
The test module is from issue #7319
#7319 (comment)

In main head

time ./build/bin/wasm-opt -Oz --enable-bulk-memory --enable-multivalue --enable-reference-types --enable-gc --enable-tail-call --enable-exception-handling  -o /dev/null ./test3.wasm

real    9m16.111s
user    35m33.985s
sys     0m51.000s

In the PR

time ./build/bin/wasm-opt -Oz --enable-bulk-memory --enable-multivalue --enable-reference-types --enable-gc --enable-tail-call --enable-exception-handling  -o /dev/null ./test3.wasm

real    5m17.170s
user    30m9.198s
sys     0m28.030s

[kripken]

1. We are called more than once with num == 0, so I think this is doing more work than needed? (there are three calls to this, two with num == 0 as the default value)
2. We may also not end up needing the cache at all, if other issues stop us earlier.
3. We will also only need the cache for some expressions, not the entire function.

To fix those issues, how about making new line 702 call a function that checks for external break targets. That function would lazily populate a cache internally, that is, given a specific expression it would compute it and cache results for that expression and all children (avoiding walking children already in the cache).

[Changqing-JING]

@kripken
Thank you for review

Addressed all three suggestions: cache is now lazily populated on first hasExitingBranches() call (avoiding work when not needed), uses unordered_set instead of map<Expression*, bool>, and a exitingBranchCachePopulated_ bool prevents redundant re-computation when the cache is empty.

[kripken]

Suggested change

	std::unordered_set<Expression*> exitingBranchCache_;
	std::unordered_set<Expression*> exitingBranchCache;

We don't use a convention like that for "internal" things.

[kripken]

Please move this down to the function that uses it. Then a single comment will work for both (atm the comment appears twice).

[kripken]

Looks like this still scans the entire function. I suggest that we only scan expr itself. That will still avoid re-computing things, but avoid scanning things that we never need to look at.

This does require that the cache store a bool, so we know if we scanned or not, and if we did, if we found branches out or not. But I think that is worth it - usually we will scan very few things.