erts: Fix bs_get_integer instruction

The instruction bs_get_integer could unnecessarily trigger a garbage collection
in failure cases which is unwanted or outright dangerous.

Ex:

    <<X:Sz,_/bits>> = <<"some binary">>

Previously, if Sz induced X to a bignum it would reserved memory size this on
the heap via a garbage collection before checking if the size could actually match.

It will now check the binary size before triggering a collection.
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.
erts: Remove overestimation of heap space in binary_to_term

for 32-bit integers (INTEGER_EXT) on 64-bit architectures.
erts: Reduce heap usage for binary_SUITE:deep
erts: Fix useless comparisons in binary_SUITE:external_size
erts: Update etp-commands with heap-dump
erts: Simplify term_to_binary by removing saved ESTACK from root set

We disabled GC (in 522a29666088d5) during trapping and don't need to
include the saved ESTACK as part of root set.
erts: Remove the extra_root feature from the process structure

as we don't use it and instead have the feature to disable GC
during trapping BIFs.
erts: Extend binary_SUITE:ttb_trap to also cover binary_to_term

and rename it 'trapping'.
erts: Run binary_SUITE:trapping even for 32bit

Not sure why it was disabled for 32bit in the first place?
erts: Fix compiler warnings for NO_JUMP_TABLE
erts: Fix benign ESTACK/WSTACK typo
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.
jinterface: Fix unicode bug in test code
erts: Refactor ESTACK & WSTACK to use a struct easy to "export"

This is not a clean refactor. It changes the behaviour slightly
of E/WSTACK_RESTORE. The allocated stack from E/WSTACK_SAVE is used
as-is and not copied into default_stack. This will hopefully fix an
illusive memory leak that valgrind is reporting.
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 'egil/fix-bs_get_integer/OTP-11581'

* egil/fix-bs_get_integer/OTP-11581:
  erts: Fix bs_get_integer instruction
Merge branch 'egil/etp-commands/OTP-11582'

* egil/etp-commands/OTP-11582:
  erts: Update etp-commands with heap-dump
Merge branch 'bjorn/compiler/fix-lift-after/OTP-11580'

* bjorn/compiler/fix-lift-after/OTP-11580:
  compiler: Silence false warning for unmatched return in 'after' clause