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.

We want to re-ident the source files after having taken out
all ?line macros. When re-indenting using Emacs, it's important
that comments that should be at the beginning of a line (or
follow the indentation of statements around it) must start with
"%%".