Strengthen beam_validator to check that the stack is initialized
when an instruction with an {f,0} operand is executed.
For example, the following code sequence:

    {allocate,0,1}.
    {bif,element,{f,0},[{integer,1},{x,0}],{x,0}}.

should not be accepted because the stack may be scanned if
element/2 fails. That could cause a crash or other undefined
behavior if garbage on the stack looks like a catch tag.

beam_validator: Strengthen validation of GC instructions

OTP-14863

beam_validator did not verify that the Y registers were initialized
before executing the following instructions that could cause a GC:

    bs_append/8
    bs_init2/6
    bs_init_bits/6
    gc_bif1/5
    gc_bif2/6
    gc_bif3/7
    test_heap/2

That means that, for example, an incorrect optimization that replaced
an 'allocate_zero' instruction with an 'allocate' instruction when it
was not safe, would not be rejected by beam_validtor, but would
instead cause a crash or other undefined behavior at runtime.

Also fix a minor bug in beam_type exposed by the stronger checking.
When compiling from .S files, beam_type did not handle the
init/1 instruction and could produce unsafe code.

The type optimizations for is_record and test_arity checked whether
the arity was equal to the size stored in the type information,
which is incorrect since said size is the *minimum* size of the
tuple (as determined by previous instructions) and not its exact
size.

A future patch to the 'master' branch will restore these
optimizations in a safe manner.

* lukas/compiler/add_to_dis/OTP-14784:
  compiler: Add +to_dis option that dumps loaded asm