A `SwitchBreak` node should not have a specific associated
`FallThroughScopeType`, since its semantics represent the fact of a
`case` of the `switch` with no associated statements, and thus can be
represented with the `FallThrough` behavior.
Change the analysis in order to lift the assumption that a dispatcher
`switch` always coveris all the values of the variable state. This is
not true after the `simplifySwitchBreak` and `inlineDispatcherSwitch`
beautify passes, which can remove some of the `case`s.
The `FallThroughScope` associated to a `ScsNode` should represent the
fact that we have fallthrough from a loop.
Without any more advanced semantical analysis, we cannot conclude that
we do not have fallthrough.
We introduce the PromoteCallNoReturn beautification pass. Its goal is to
restructure sequence of statements, in order to have `call`s to
`noreturn` functions as _inlined_ in the middle of the statement
sequence, and leave _non local control flow statements_ at the end of
that scope. E.g., we prefer:
```
if (cond)
call noreturnfunc();
return;
```
to
```
if (!cond)
return;
call noreturnfunc();
```
In order to do this, contextually, we restructure the routine computing
the `fallthrough` property, in order to be able to differentiate between
the _non local control flow statements_, a call to a `noreturn`
function, or a generic mix of the two (useful when combining results
from the two situations above).
The new analysis is also used in the `promoteNoFallThrough` promotion
pass.
Alessandro Di Federico