Eliminate bottlenecks in sys_core_fold

Compiling programs with very many uses of the "dot notation"
for extracting a record element could be very slow. The reason
is that each extraction of a record element (R#r.a) would first be
transformed to code like this:

   case R of
     {r,rec0,_,_} -> rec0;
      _ -> error({badrecord,r})
   end

In Core Erlang, each '_' would be become a new variable. The
resulting code would be optimized by sys_core_fold, but the
optimization process could be very slow.

Profiling shows that sub_del_var/2 was the worst bottleneck, and the
sub_is_val/2 the second worst bottleneck. In both cases, the culprit
is the linear traversal of a very long list (the list of variable
substitutions). Fortunately, there already is a gb_set (the scope)
which contains all variables that are currently live. If a variable is
not known to be live, it is no point in doing the linear operation on
the list.
Ignore warnings when running sys_core_fold after inlining

The new inliner (cerl_inline) does not mark inlined code as compiler
generated. Therefore, when sys_core_fold is run after inlining, it
may generate spurious warnings.

The easiest way out (for now, at least) is to discard all warnings
found when running sys_core_fold after inlining.
compiler tests: Test exporting rules for andalso/orelse
Merge branch 'nox/fix-dbg_ieval-exporting-rules/OTP-11553'

* nox/fix-dbg_ieval-exporting-rules/OTP-11553:
  compiler tests: Test exporting rules for andalso/orelse
  Fix evaluation of andalso and orelse in the debugger
compiler: Correct line number in exception from binary construction

Reported-by: Stanislav Seletskiy
Generalize optimizations of case statements

Case expressions such as:

  case {Expr1,Expr} of
     {V1,V2} -> ...
  end

are already optimized to not actually build the tuple. Generalize
the optimization to avoid building any kind of composite term,
such as:

  case {ok,[A,B]} of
    {ok,[X,Y]} -> ...
  end

We don't expect programmers to write such code directly, but
inlining can produce such code.

We need to be careful about the warnings we produce. If the case
expression is a literal, it is expected that no warnings should be
produced for clauses that don't match. We must make sure that we
continue to suppress those warnings.
compiler: Silence false warning for unmatched return in 'after' clause

Because 26940a8c0c lifted code in the 'after' clause of 'try' to
a new function, Dialyzer could produce false warnings for code such
as:

   try
     ...
   after
     file:close(F)
   end.

Mark the the call to the generated function as 'compiler_generated'
to silence the warning.
Merge branch 'bjorn/fix-line-number-in-bs-exception/OTP-11572'

* bjorn/fix-line-number-in-bs-exception/OTP-11572:
  compiler: Correct line number in exception from binary construction
Merge branch 'bjorn/compiler/optimizations/OTP-11584'

* bjorn/compiler/optimizations/OTP-11584:
  Generalize optimizations of case statements
  Ignore warnings when running sys_core_fold after inlining
Fix testing with unicode paths

re needs unicode option