In order to optimize calls to block_given? that end up in the
expected core method, this patch alters compilation of fcall
block_given? to overload the BlockGivenInstr used by the frameless
defined?(yield) logic. When this instr is used for defined?,
nothing changes. When used for a bare fcall to block_given?, the
logic will first check if the target method is built-in, using the
fast defined?(yield) logic in that case or falling back on a
normal invocation otherwise.

Moving this into an instruction avoids having to add special logic
in CallInstr/CallBase and friends to capture block_given? calls
and give them special behavior. Specifically, the frame flags
specified in the block_given? definition do not have to be
ignored; rather, they only apply in cases where we are calling the
method in other ways, such as on a target object (e.g.
Kernel.block_given?) or via metaprogramming calls like send. This
simplifies the optimization, since BlockGivenInstr itself does not
need a caller frame in order to handle both built-in and custom
block_given?, and any non-direct calls to block_given? continue to
deoptimize in the same way as before.

Performance of a method containing block_given? is now equal to a
method using the less-common defined?(yield) without introducing
any incompatibility.

The latter form avoids any caller frame requirement since it just
takes the block in hand and checks if it is given. The former
form has typically required a caller frame, since it performs a
normal fcall to block_given? which then needs to be able to see
the caller's received block.

The optimized block_given? still needs to be treated as a call,
which would pollute the flags for defined?(yield) unnecessarily.
This patch moves it to its own instr.