This makes sure that the SSA optimizations are not essential and
may help to cover more code in beam_ssa_pre_codegen and
beam_ssa_codegen.

This serves as a base for the upcoming module-level type
optimization, but may come in handy for other passes like
beam_ssa_funs and beam_ssa_bsm that have their own ad-hoc
implementations.

OTP 22 extends the binary instructions to support a Y register
destination. When giving an option to compile for an earlier
release, make sure that binary instructions don't use a Y register
destination, by rewriting the binary instructions to use an X
register destination and adding a `move` instruction to move
the value to the Y register.

v3_codegen is replaced by three new passes:

* beam_kernel_to_ssa which translates the Kernel Erlang format
  to a new SSA-based intermediate format.

* beam_ssa_pre_codegen which prepares the SSA-based format
  for code generation, including register allocation. Registers
  are allocated using the linear scan algorithm.

* beam_ssa_codegen which generates BEAM assembly code from the
  SSA-based format.

It easier and more effective to optimize the SSA-based format before X
and Y registers have been assigned.  The current optimization passes
constantly have to make sure no "holes" in the X register assignments
are created (that is, that no X register becomes undefined that an
allocation instruction depends on).

This commit also introduces the following optimizations:

* Replacing of tuple matching of records with the is_tagged_tuple
instruction. (Replacing beam_record.)

* Sinking of get_tuple_element instructions to just before the first
use of the extracted values. As well as potentially avoiding
extracting tuple elements when they are not actually used on all
executions paths, this optimization could also reduce the number
values that will need to be stored in Y registers. (Similar to
beam_reorder, but more effective.)

* Live optimizations, removing the definition of a variable that is
not subsequently used (provided that the operation has no side
effects), as well strength reduction of binary matching by replacing
the extraction of value from a binary with a skip instruction. (Used
to be done by beam_block, beam_utils, and v3_codegen.)

* Removal of redundant bs_restore2 instructions. (Formerly done
by beam_bs.)

* Type-based optimizations across branches. More effective than
the old beam_type pass that only did type-based optimizations in
basic blocks.

* Optimization of floating point instructions. (Formerly done
by beam_type.)

* Optimization of receive statements to introduce recv_mark and
recv_set instructions. More effective with far fewer restrictions
on what instructions are allowed between creating the reference
and entering the receive statement.

* Common subexpression elimination. (Formerly done by beam_block.)

The goal of this pass is to find values that are built from
patterns and generate aliases for those values to remove
pressure from the GC. For example, this code:

   example({ok, Val}) ->
       {ok, Val}.

shall become:

   example({ok, Val} = Tuple) ->
       Tuple.

Currently this pass aliases tuple and cons nodes made of literals,
variables and other cons. The tuple/cons may appear anywhere in the
pattern and it will be aliased if used later on.

Notice a tuple/cons made only of literals is not aliased as it may
be part of the literal pool.

Two dummy .erl files are created while releasing the tests for
the compiler.  Remove the files after they have been copied to
the release directory to avoid that they show up as untracked
files in the output of "git status".

Ensure that correct (not necessarily optimal) code is generated for
Core Erlang code not originating from v3_core.

The guard optimizations in v3_kernel has removed the need for
beam_bool.

The filters in a list comprehension can be guard expressions or
an ordinary expressions.

If a guard expression is used as a filter, an exception will basically
mean the same as 'false':

  t() ->
    L = [{some_tag,42},an_atom],
    [X || X <- L, element(1, X) =:= some_tag]
    %% Returns [{some_tag,42}]

On the other hand, if an ordinary expression is used as a filter, there
will be an exception:

  my_element(N, T) -> element(N, T).

  t() ->
    L = [{some_tag,42},an_atom],
    [X || X <- L, my_element(1, X) =:= some_tag]
    %% Causes a 'badarg' exception when element(1, an_atom) is evaluated

It has been allowed for several releases to override a BIF with
a local function. Thus, if we define a function called element/2,
it will be called instead of the BIF element/2 within the module.
We must use the "erlang:" prefix to call the BIF.

Therefore, the following code is expected to work the same way as in
our second example above:

-compile({no_auto_import,[element/2]}).

element(N, T) ->
    erlang:element(N, T).

t() ->
    L = [{some_tag,42},an_atom],
    [X || X <- L, element(1, X) =:= some_tag].
    %% Causes a 'badarg' exception when element(1, an_atom) is evaluated

But the compiler refuses to compile the code with the following
diagnostic:

  call to local/imported function element/2 is illegal in guard