Previously, because we only had one yield instruction and one
way to prepare any incoming block, the lowest-common-denominator
was to always turn passed blocks into a Proc object before sending
it on to a yield. This is less overhead than in 1.7, and resulted
in our yield performance being worse than it should be. See #2442.

In order to fix this I have made the following changes.

* ReceiveClosure, the instruction which reifies an implicit block
  into a Proc, has been renamed to ReifyClosure. It is now used
  only for block args, as in def foo(&b).
* LoadImplicitClosure and LoadFrameClosure are added to retrieve
  a block from either the JVM stack or from our frame stack.
  Method bodies and singleton class bodies use the stack, and all
  other scopes use frame. This allows us to load the block used
  for yielding in an efficient way regardless of which scope we
  are in.
* IRScope temporarily aggregates two variables: one for the
  "yield" closure, the one used for yielding (which may come from
  either JVM stack or our frame); and one for the "implicit"
  closure, which is the one passed directly to this scope on the
  JVM stack. This additional closure is needed to represent
  two-block scopes like a block that receives a block.
* ProcessModuleBody now has an operand to load a block passed to
  the module/class body. For normal module and class bodies this
  is always NullBlock (new operand for Block.NULL_BLOCK), but
  singleton class bodies (class << obj) inherit the surrounding
  scope's yield closure (not the implicit closure, since that
  would capture nearest block's block rather than outer method's
  block).

This results in a substantial reduction of allocation, and a
decent performance improvement:

BEFORE

               yield      6.901M (±19.0%) i/s -     32.351M
          block.call      6.509M (±10.6%) i/s -     31.999M
     method dispatch     18.988M (±16.8%) i/s -     90.797M

AFTER

               yield      8.002M (±22.4%) i/s -     36.745M
          block.call      6.399M (±12.8%) i/s -     31.314M
     method dispatch     18.939M (±10.5%) i/s -     92.585M