Kernel#lambda: return forwarded block as non-lambda proc

[XrXr]

Before this commit, Kernel#lambda can't tell the difference between a
directly passed literal block and one passed with an ampersand.

A block passed with an ampersand is semantically speaking already a
non-lambda proc. When Kernel#lambda receives a non-lambda proc, it
should simply return it.

Implementation wise, when the VM calls a method with a literal block, it
places the code for the block on the calling control frame and passes a
pointer (block handler) to the callee. Before this commit, the VM
forwards block arguments by simply forwarding the block handler, which
leaves the slot for block code unused when a control frame forwards its
block argument. I use the vacant space to indicate that a frame has
forwarded its block argument and look for this in Kernel#lambda to
detect forwarded blocks.

This is a very ad-hoc solution and relies heavily on the way block
passing works in the VM. However, it's the most self-contained solution
I have.

Bug #15620

[XrXr]

It looks like this changes the semantics of calling into lambda using zsuper. Will look for solutions

EDIT: Okay, found a way to do it.

[XrXr]

The extra specs are just for making sure I didn't make unintentional semantic changes. I checked that they pass on supported versions and on master.

Some notes:

• it's not enough to simply check whether lambda got a forwarded block since it needs to behave differently for block forwarded using & vs super
• another possible solution is to make block handler an offset from the bottom of the stack plus a tag, packed into a VALUE. It would be a bigger change that might have wider perf consequences
• I tried using another tag for the block handler (it's already tagged), but there aren't enough bits for another tag on 32 bit platforms #2288

[XrXr]

Updated to issue a warning in cases where Kernel#lambda (unintuitively) returns the proc it receives.

[eregon]

👍 for the warning.

I'm not sure about the super cases, it seems extremely uncommon to have a method named lambda and call super in it. But it's probably best to keep behavior as it-is in this PR.