Fix duplicated block in control flow uplifting

[Y-Nak]

What was wrong?

close #749
The problem is that the same basic block is included in serialized StructuralInst and then translated into yul more than once in the below CFG condition.

1. CFG doesn't have a canonical exit block
2. Two paths can be merged at a certain block

e.g.,

In this CFG, bb2 is a merge block of two paths, bb0 -> bb1 -> bb4 -> bb2 and bb0 -> bb2.
But the compiler can't find merge block properly, and it lead to ICE as a result.

How was it fixed?

I wrongly assumed that if merge block should be the post dominator of if header.
To find if merge block correctly, we should follow the below algorithm.

1. Findif merge block candidate

When we see the branch instruction in a non-loop header, we can find a merge block candidate by applying the following criteria to two destination blocks of the branch instruction respectively.

block `cand` can be a candidate of a `merge` block iff
  1. `cand` is a dominance frontier of `block`.
  2. `cand` is NOT  a dominator of `block`.
  3. `cand` is NOT a "merge" block of a parent `if`.
  4. `cand` is NOT a "loop_exit" block of parent `loop`.

2. Find merge block.

We can find the merge block according to the result of 1..

a. When both destinations have the same candidate, then the candidate is the merge block.

b. When only one of the destinations has a candidate, then the candidate is the merge block iff the candidate is identical to another destination that doesn't have a candidate.

c. When none of the destinations has a candidate, then a `block` is the merge block iff 
  1. the `block` is the post dominator of the `branch` instruction's block
  2. the `block` is inside the same loop if the `branch` instruction's block is in a loop.

To-Do

• OPTIONAL: Update Spec if applicable

• Add entry to the release notes (may forgo for trivial changes)

• Clean up commit history

[cburgdorf]

Looks good!