Type subtraction never resulted in the 'none' type, even when it
was obvious that it should. Once that was fixed it became apparent
that inequality checks also fell into the same subtraction trap
that the type pass warned about in a comment.

This then led to another funny problem with select_val, consider
the following code:

    {bif,'>=',{f,0},[{x,0},{integer,1}],{x,0}}.
    {select_val,{x,0},{f,70},{list,[{atom,false},{f,69},
                                    {atom,true},{f,68}]}}.

The validator knows that '>=' can only return a boolean, so once it
has subtracted 'false' and 'true' it killed the state because all
all valid branches had been taken, so validation would crash once
it tried to branch off the fail label.

The current type conflict resolution works well for the example
case in the comment, but doesn't handle branched code properly,
consider the following:

  {label,2}.
    {test,is_tagged_tuple,{f,ignored},[{x,0},3,{atom,r}]}.
    {allocate_zero,2,1}.
    {move,{x,0},{y,0}}.
    %% {y,0} is known to be {r, _, _} now.
    {get_tuple_element,{x,0},2,{x,0}}.
    {'try',{y,1},{f,3}}.
    %% ... snip ...
    {jump,{f,5}}.
  {label,3}.
    {try_case,{y,1}}.
    %% {x,0} is the error class (an atom), {x,1} is the error term.
    {test,is_eq_exact,{f,ignored},[{x,0},{y,0}]}.
    %% ... since tuples and atoms can't meet, the type of {y,0} is
    %% now {atom,[]} because the current code assumes the type
    %% we're updating with.
    {move,{x,1},{x,0}}.
    {jump,{f,5}}.
  {label,5}.
    %% ... joining tuple (block 2) and atom (block 3) means 'term',
    %% so the get_tuple_element instruction fails to validate
    %% despite this being unrechable from block 3.
    {test_heap,3,1}.
    {get_tuple_element,{y,0},1,{x,1}}.
    {put_tuple2,{x,0},{list,[{x,1},{x,0}]}}.
    {deallocate,2}.
    return.

This commit kills the state on type conflicts, making unreachable
instructions truly unreachable.

This commit improves the bit-syntax match optimization pass,
leveraging the new SSA intermediate format to perform much more
aggressive optimizations. Some highlights:

* Watch contexts can be reused even after being passed to a
  function or being used in a try block.
* Sub-binaries are no longer eagerly extracted, making it far
  easier to keep "happy paths" free from binary creation.
* Trivial wrapper functions no longer disable context reuse.

Waiting messages for a process may be stored in a queue
outside of any heap or heap fragment belonging to the process.
This is an optimization added in a recent major release to
avoid garbage collection messages again and again if there
is a long message queue.

Until such message has been matched and accepted by
the remove_message/0 instruction, the message must not be
included in the root set for a garbage collection, as that
would corrupt the message. The loop_rec/2 instruction explicitly
turns off garbage collection of the process as long messages
are being matched.

However, if the compiler were to put references to a message
outside of the heap in an Y register (on the stack) and there
happened to be a GC when the process had been scheduled out,
the message would be corrupted and the runtime system would
crash sooner or later.

To ensure that doesn't happen, teach beam_validator to check
for references on the stack to messages outside of the heap.

Every catch or try/catch must use a lower Y register number than any
enclosing catch or try/catch. That will ensure that when the stack
is scanned when an exception occurs, the innermost try/catch tag is
found first.

Make sure that there is the correct number of put/1 instructions
following put_tuple/2. Also make it illegal to reference the
register for the tuple being built in a put/1 instruction.
That is, beam_validator will now issue a diagnostice for the the
following code:

    {put_tuple,1,{x,0}}.
    {put,{x,0}}.

In 45f469ca0890, the BEAM loader started to use x(1023) as scratch
register for some instructions. Therefore we should not allow
x(1023) to be used in code emitted by the compiler.

The run-time system stopped paying attention the 'aligned' flag in bit
syntax construction and matching when bitstrings were introduced in
language.

The beam_asm compiler pass will crash if the 'aligned' flag is given
in bit syntax instructions.

beam_validator still validates the 'aligned' flag. Before
912fea0b712a (which removed the possibility to validate existing
BEAM files), the 'aligned' flag could actually be encountered
when validating a BEAM file.

Since the validation of 'aligned' no longer serves any useful
purpose, remove the validation code.

set_type_y/3 is far too complicated. Note that we don't need to check
the #st.numy field, because we will detect the error anyway because
the information for the y register will be missing in the #st.y
gb_tree.

There is also a clause that would never match because of a spelling
error (the first "n" was missing in "uninitialized"). That clause
is not needed because the default clause will do fine.

Furthermore, we can break out the special case for handling catch_end
and similar instructions into a new function.

The fault/1,2 BIF was removed a long time ago.