Consider this pseudo code:

    f(...) ->
      Val = case Expr of
        ... ->
          ... ;
        ... ->
          ... ;
        ... ->
          my_abort(something_went_wrong)
      end,
      %% Here follows code that uses Val.
      .
      .
      .

    my_abort(Reason) ->
      throw({error,Reason}).

The first two clauses in the case will probably provide some
information about the type of the variable `Var`, information
that would be useful for optimizing the code that follows the
case.

However, the third clause would ruin everything. The call
to `my_abort/1` could return anything, and thus `Val` could
also have any type.

294d66a295f6 introduced module-level type analysis, which will in
general keep track of the return type of a local function
call. However, it does not improve the optimization for this specific
function. When a function never returns, that is, when its type is
`none`, it does not propagate the `none` type, but instead pretends
that the return type is `any`.

This commit extends the handling of functions that don't return to
properly handle the `none` type. Any instructions that directly
follows the function that does not return will be discarded, and the
call will be rewritten to a tail-recursive call.

For this specific example, it means that the type for `Val` deduced
from the first two clauses will be retained and can be used for
optimizing the code after the case.

Prior to this change, calls inside binaries were
treated as top level which would cause the `Fun(Arg)`
call inside `<<Fun(Arg)/binary>>` to return an internal
dbg_ieval tuple and ultimately error with badarg.

The efile driver will soon be reimplemented as a BIF.

Instead of opening a port based on efile, use hd(erlang:ports()).  It
is a reasonable safe assumption that the runtime will continue to use
use at least some ports.

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

This speeds up the compilation of binary literals
with string values in them. For example, compiling
a file with a ~340kB binary would yield the following
times by the compiler:

    Compiling "foo"
     parse_module       :   0.130 s    5327.6 kB
     transform_module   :   0.000 s    5327.6 kB
     lint_module        :   0.011 s    5327.8 kB
     expand_module      :   0.508 s   71881.2 kB
     v3_core            :   0.463 s      11.5 kB

Notice the increase in memory and processing time
in expand_module and v3_core. This happened because
expand_module would expand the string in binaries
into chars. For example, the binary <<"foo">>, which
is represented as

    {bin, 1, [
      {bin_element, 1, {string, 1, "foo"}, default, default}
    ]}

would be converted to

    {bin, 1, [
      {bin_element, 1, {char, 1, $f}, default, default},
      {bin_element, 1, {char, 1, $o}, default, default},
      {bin_element, 1, {char, 1, $o}, default, default}
    ]}

However, v3_core would then traverse all of those
characters and convert it into an actual binary, as it
is a literal value.

This patch addresses this issue by moving the expansion
of string into chars to v3_core and only if a literal
value cannot not be built. This reduces the compilation
time of the file mentioned above to the values below:

    Compiling "bar"
     parse_module       :   0.134 s    5327.6 kB
     transform_module   :   0.000 s    5327.6 kB
     lint_module        :   0.005 s    5327.8 kB
     expand_module      :   0.000 s    5328.7 kB
     v3_core            :   0.013 s      11.2 kB

While we are it, also re-ident the files.