[TypeRefining] Fix block-nested pops

[tlively]

When ReadUpdater replaces trapping or unreachable reads with a sequence block, or when WriteUpdater replaces writes to bottom-type fields with a sequence block, any pop instruction in the wrapped operand becomes nested inside a block. Track when blocks are added in both updaters and call EHUtils::handleBlockNestedPops at the end of the function walk.

[gemini-code-assist]

Code Review

This pull request updates the TypeRefining pass to handle block-nested pops created when updating writes to and reads from refined fields, using EHUtils::handleBlockNestedPops. Feedback on the changes highlights that the addedBlock flag in ReadUpdater is not reset after visiting a function, which can lead to state carry-over and unnecessary processing when the updater is reused across multiple functions. Resetting addedBlock to false inside visitFunction is recommended.

[gemini-code-assist]

In sequential/single-threaded execution mode, the same ReadUpdater instance is reused across all functions in the module. If addedBlock is set to true in one function, it will carry over to all subsequent functions, causing EHUtils::handleBlockNestedPops to be run unnecessarily on them. Resetting addedBlock to false at the end of visitFunction prevents this state carry-over and avoids unnecessary performance overhead.

      void visitFunction(Function* func) {
        if (addedBlock) {
          EHUtils::handleBlockNestedPops(func, *getModule());
          addedBlock = false;
        }
      }

[tlively]

This is not the case because the pass is function-parallel. Every function gets a fresh instance.