An assertion in code generation would fail when the common exit
block was ?BADARG_BLOCK, as some operations expect to always "fail"
directly to that block (= throw an exception) and we had inserted
a dummy block in between.

Other operations could also get funny fail labels, jumping to
blocks that immediately jumped to {f,0}, but these were all cleaned
up by beam_jump, sweeping the bug under the rug.

* john/compiler/fix-fail-path-exceptions-bsm/OTP-15946:
  beam_ssa_bsm: Leave ?BADARG_BLOCK alone when cloning fail path

* john/compiler/fix-unsafe-tuple_size-opt/OTP-15945:
  beam_ssa_opt: Do not apply tuple_size optimization outside guards

This fix is rather ugly and tacked-on, but I'm not comfortable
refactoring the pass in an emergency patch.

Rewriting `tuple_size` to `is_tuple` + `tuple_size` will cause it
not to throw an exception, either crashing the compiler or the
emulator when the code runs.

* john/compiler/fix-bad-bitstring-type-opt/OTP-15872:
  beam_ssa_type: Fix incorrect bitstring unit determination

The following sequence would be wrongly optimized into a
i_get_tuple_element2 instruction, reading an element from the
wrong tuple:

    {get_tuple_element,{x,0},1,{x,0}}.
    {get_tuple_element,{x,0},2,{x,1}}.

The compiler would treat the "Unit" of bs_init instructions as
the unit of the result instead of the required unit of the input,
causing is_binary checks to be wrongly optimized away.

* bjorn/compiler/fix-beam_ssa_dead-patch/OTP-15845:
  Fix unsafe optimizations where guard tests could be removed