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

num_bif_SUITE.erl was originally copied from the emulator test
suite. It does not test much of the compiler.

Therefore, remove num_bif_SUITE. Add a new test to bif_SUITE
to test trunc/1 and round/1 in contexts that could be tricky
for the compiler to handle correctly. Note that there is no
need to test abs/1 in bif_SUITE, since it is tested in many
other places (e.g. in guard_SUITE).

beam_validator wrongly complained that the following was
not safe because it didn't know that is_bitstring/1 is safe:

  food(Curriculum) ->
    [try
       is_bitstring(functions)
     catch _ ->
       0
     end, Curriculum].

While we are it, also add a new bif_SUITE test suite to cover some
more code in beam_validator.

In complicated code with many indirect jumps to the func_info label,
a label could get lost.

It's time that we have a dedicated test suite for beam_bool.

Consider this code:

    %% Start of block
    get_tuple_element Tuple 0 Element
    get_map_elements Fail Map [Key => Dest]
    .
    .
    .
    move Element UltimateDest
    %% End of block

  Fail:
    %% Code that uses Element.

beam_block (more precisely, otp_tuple_element/1) would
incorrectly transform the code to this:

    %% Start of block
    get_map_elements Fail Map [Key => Dest]
    .
    .
    .
    get_tuple_element Tuple 0 UltimateDest
    %% End of block

  Fail:
    %% Code that uses Element.

That is, the code at label Fail would use register Element,
which is either uninitalized or contains the wrong value.

We could fix this problem by always keeping label information
at hand when optimizing blocks so that we could check the code
at the failure label for get_map_elements. That would require
changes to beam_block and beam_utils. We might consider doing
that in the future if it turns out be worth it.

For now, I have decided that I want to keep the simplicity of blocks
(allowing them to be optimized without keeping label information).
That could be achieved by not including get_map_elements in
blocks. Another way, which I have chosen, is to only allow
get_map_elements as the first instruction in the block.

For background on the bug: c288ab8 introduced the beam_reorder pass
and 5f431276 introduced opt_tuple_element() in beam_block.

Since no test suites includede test_server.hrl, there is no need
to have test_server in the include path or code path.