Emitting unreachable for unemittable String instructions can fail due to blocks

https://github.com/WebAssembly/binaryen/pull/6415 solves most of the problem (see details there), but an exception is this:

(string.new_wtf16_array
 (ref.as_non_null
  (block (result (ref null $array))
   (ref.as_non_null
    (ref.null none)
   )
  )
 )
 (i32.const 0)
 (i32.const 0)
)

The block upcasts the type from a bottom type to some specific array type. However, in our binary emitter we do not emit blocks without names (since they have no branches to them), and without that block, we have a bottom type - but the logic in #6415 does not see that, as it scans the IR and not what we emit.

We could perhaps fix this by emitting blocks without names if they upcast types. That should not affect optimized builds, but it could affect unoptimized ones. Alternatively, we could scan what is actually emitted rather than the IR, but that would take some significant refactoring to track what we emit. We could also just do getFallthrough to look through such blocks, at the cost of extra work. However, if the stringref spec is changed/fixed then we don't need any of that.

Start by reading PR #6415 and the binary emitter behavior for the provided string.new_wtf16_array example, focusing on how unnamed blocks and bottom-type upcasts are handled. Compare the IR with what is actually emitted and determine which approach prevents emitting unreachable for the unemittable instruction without regressing unoptimized builds.