In some circumstances, as when inlining code, when some optimization
passes are disabled or with hand-written but semantically correct Core
Erlang or BEAM assembly, a fresh reference may be live in more than one
register:

    ...
    {allocate_zero,2,2}.
    ...
    {call_ext,0,{extfunc,erlang,make_ref,0}}. % Ref in [x0]
    ...
    {move,{x,0},{y,0}}. % Ref in [x0,y0]
    {move,{y,1},{x,0}}. % Ref in [y0]
    ...
    {move,{y,0},{x,0}}. % Ref in [x0,y0]
    {move,{x,0},{y,1}}. % Ref in [x0,y0,y1]
  {label,5}.
    {loop_rec,{f,6},{x,0}}. % Ref in [y0,y1]
    ...
    {loop_rec_end,{f,5}}.
  {label,6}.
    {wait,{f,5}}.
    ...

Pass beam_receive expects a single live register for the ref when it
encounters the loop_rec instruction and crashes with the following
reason:

$ erlc t.S
...
crash reason: {{case_clause,
                   {'EXIT',
                       {{case_clause,[{y,1},{y,0}]},
                        [{beam_receive,opt_recv,5,
                             [{file,"beam_receive.erl"},{line,154}]},
                         ...]}}},
               ...}

This commit teaches beam_receive how to use a set of registers instead
of a single one when tracking fresh references, thus avoiding the crash.

beam_jump moves short code sequences ending in an instruction that causes
an exception to the end of the function, in the hope that a jump around
the moved blocked can be replaced with a fallthrough. Therefore, moving
a block that is entered via a fallthrough defeats the purpose of the
optimization.

Also add two more test cases for the beam_receive module to ensure that
all lines are still covered.

We don't attempt to run the generated code, but use beam_disasm
and check for the presence or absence (as appropriate) of the
recv_mark/1 and recv_set/1 instructions.