As part of sys_core_fold, variables involved in bit syntax
matching would be annotated when it would be safe for a later
pass to do the delayed sub-binary creation optimization.

An implicit assumption regarding the annotation was that the
code must not be further optimized. That assumption was broken
in 05130e48555891, which introduced a fixpoint iteration
(applying the optimizations until there were no more changes).
That means that a variable could be annotated as safe for
reusing the match context in one iteration, but a later iteration
could rewrite the code in a way that would make the optimization
unsafe.

One way to fix this would be to clear all reuse_for_context
annotations before each iteration. But that would be wasteful.

Instead I chose to fix the problem by moving out the annotation
code to a separate pass (sys_core_bsm) that is run later after
all major optimizations of Core Erlang has been done.

Rewrite the instruction stream on tagged tuple tests.
Tagged tuples means a tuple of any arity with an atom as its first element.
Typically records, ok-tuples and error-tuples.

from:
    ...
    {test,is_tuple,Fail,[Src]}.
    {test,test_arity,Fail,[Src,Sz]}.
    ...
    {get_tuple_element,Src,0,Dst}.
    ...
    {test,is_eq_exact,Fail,[Dst,Atom]}.
    ...
to:
    ...
    {test,is_tagged_tuple,Fail,[Src,Sz,Atom]}.
    ...

The guard optimizations in v3_kernel has removed the need for
beam_bool.

The previous commits have made sys_pre_expand superfluous. Since
sys_pre_expand is undocumented and unsupported it can be removed in
a major release without prior deprecation.

Also remove code in erl_parse that handles abstract code that has
passed through sys_pre_expand.

We considered deprecating sys_pre_expand just in case, but decided
against it for the following reasons:

- Anyone brave and knowledgeable enough to use sys_pre_expand should
be able to cope with sys_pre_expand being removed.

- If we kept it, but didn't test it anywhere in OTP, it could
potentially stop working. So we would probably have to add some test
cases.

In the future we might want to add more bit syntax optimizations,
but beam_block is already sufficiently complicated. Therefore, move
the bit syntax optimizations out of beam_block into a separate
compiler pass called beam_bs.

When matching tuples, the pattern matching compiler would generate
code that would fetch all elements of the tuple that will ultimately
be used, *before* testing that (for example) the first element is the
correct record tag. For example:

  is_tuple Fail {x,0}
  test_arity Fail {x,0} 3
  get_tuple_element {x,0} 0 {x,1}
  get_tuple_element {x,0} 1 {x,2}
  get_tuple_element {x,0} 2 {x,3}
  is_eq_exact Fail {x,1} some_tag

If {x,2} and {x,3} are not used at label Fail, we can re-arrange the
code like this:

  is_tuple Fail {x,0}
  test_arity Fail {x,0} 3
  get_tuple_element {x,0} 0 {x,1}
  is_eq_exact Fail {x,1} some_tag
  get_tuple_element {x,0} 1 {x,2}
  get_tuple_element {x,0} 2 {x,3}

Doing that may be beneficial in two ways.

If the branch is taken, we have eliminated the execution of two
unnecessary instructions.

Even if the branch is never or rarely taken, there is the possibility
for more optimizations following the is_eq_exact instructions.
For example, imagine that the code looks like this:

  get_tuple_element {x,0} 1 {x,2}
  get_tuple_element {x,0} 2 {x,3}
  move {x,2} {y,0}
  move {x,3} {y,1}

Assuming that {x,2} and {x,3} have no further uses in the code
that follows, that can be rewritten to:

  get_tuple_element {x,0} 1 {y,0}
  get_tuple_element {x,0} 2 {y,1}

When should we perform this optimization?

At the very latest, it must be done before opt_blocks/1 in
beam_block which does the elimination of unnecessary moves.
Actually, we want do the optimization before the blocks have
been established, since moving instructions out of one block
into another is cumbersome.

Therefore, we will do the optimization in a new pass that is
run before beam_block. A new pass will make debugging easier,
and beam_block already has a fair number of sub passes.