SubtypingDiscoverer: Handle values flowing out of br_if

[kripken]

Consider

(br_if $target
  (value)
  (condition)
)

The value here must be a subtype of the thing the br_if flows into,
and also of the block it targets - the value is sent twice, effectively,
so it has two subtyping constraints. We were missing the value
flowing out.

[tlively]

Can we add an Unsubtyping lit test for this instead? That will be less code and easier to maintain with auto-update scripts.

[kripken]

Unfortunately no. Here is what such a testcase would look like:

(module
 (type $super (sub (struct)))
 (type $sub (sub $super (struct)))

 (func $block-fallthrough
  (local $super (ref $super))
  (drop
   (block $l (result (ref $sub))
    ;; The value flowing out of the br_if requires $sub <: $super
    (local.set $super
     (br_if $l
      (struct.new $sub)
      (i32.const 0)
     )
    )
    (unreachable)
   )
  )
 )
)

This PR adds a subtyping link from the br_if to its value child, but this testcase works without it: Unsubtyping also sees the connection between the local.set to the br_if, using the br_if's type. So the wasm type system helps us here. This is, I assume, why we didn't see this bug without the fuzzer.

The fuzzer hits this issue because it needs to know more than Unsubtyping. Unsubtyping infers we must keep the subtyping in this testcase - it only cares about the type level - while when the fuzzer mutates, it needs to know which types it can replace specific things with. We do need the link between the br_if and its child, for that: That informs us about the child, so we know what types it can contain.