ab03678e introduced an optimization in the beam_z pass that could
introduce unreachable code in BEAM files (a 'jump' instruction is
removed after a 'raise' instruction, but the code following the
target of the 'jump' is not removed).

Since this situation happens very rarely, there is no point in adding
another pass that can remove unreachable code after beam_z. Instead we
will make sure that beam_validator can skip the unreachable code.
Skipping unreachable code is already done in valfun_1/2 (for
historical reasons), but we will also need to do it in val_dsetel/2.

Moving a fun into a guard may cause code that is not accepted
by beam_validator.

It is not safe to share code between 'catch' blocks.

beam_block has an optimization that only is safe when it is applied
immediately after code generation. That is pointed out in a comment:

  NOTE: Moving allocation instructions is only safe because it is done
  immediately after code generation so that we KNOW that if {x,X} is
  initialized, all x registers with lower numbers are also initialized.
  That assumption may not be true after other optimizations, such as
  the beam_utils:live_opt/1 optimization.

The new beam_reorder pass added in OTP 19 runs before beam_block.
Therefore, the optimization is potentially unsafe. The optimization
is also unsafe if compilation is started from assembly code in a
.S file.

Rewrite the optimization to make it safe. See the newly added comment
for details.

ERL-202

This reverts commit 105c5b0071056dc062797e58772e098d2a3a4627.

* aronisstav/compiler/fix-compile-forms-spec/PR-1109:
  Fix spec of compile:(noenv_)forms/2

Any exceptions at this point would be of class error, not exit.

When the compiler fails to write an output file, it used to just print
"error writing file".  With this change, it also prints the error
reason:

    $ echo "-module(foo)." > foo.erl
    $ chmod -w .
    $ erlc foo.erl
    /tmp/bar/foo.bea#: error writing file: permission denied

The input for a call to compile:(noenv_)forms/2 can also be a cerl
module (useful e.g. to resume with 'from_core' after a 'to_core'
compilation).

Internal representations used for 'from_asm' and 'from_beam'
compilation can also be valid, but have no relevant types defined.