b89044a800c4 introduced an optimization that tries to delay creation
of stack frames. It turns out that this optimization is not always
safe. (See the new test case for an example.)

Since the code generator is completely rewritten in the `master`
branch for the upcoming OTP 22 release, it does not make sense trying
to mend this optimization. It is better to remove it.  Out of a sample
of about 1000 modules in OTP, about 50 of them are changed as a result
of removing this optimization.

The compiler in OTP 22 will do the same optimization in a cleaner,
safer, and more effective way.

https://bugs.erlang.org/browse/ERL-807

The `sys_core_fold` pass of the compiler would optimize
away the building of the stacktrace in code such as:

    try
        ...
    catch
        C:R:Stk ->
           erlang:raise(C, {R,Stk}, Stk)
    end

That optimization is unsafe and would cause a crash in a later compiler
pass.

There could be an internal consistency failure when using is_function/2,
because an optimization did not take into account that is_function/2 can fail.

https://bugs.erlang.org/browse/ERL-778

* maint-21:
  Updated OTP version
  Prepare release

`beam_jump` could remove a `put_tuple` instruction when the
tuple would not be used, but it would leave the following
`put` instructions. Make sure they are removed.

https://bugs.erlang.org/browse/ERL-759

* john/compiler/bs_match-anno-liveness-fix/OTP-15353/ERL-753:
  beam_utils: Handle bs_start_match2 in anno_defs