This was never part of Ruby and a misunderstanding that Ruby does
not support this.

The feature was never hit because people tend to target MRI first
so we never had people doing this.  Recent Rails find_by logic exposed
a bug in this feature which would CCE.

Removing this fixes the CCE.

The second part of this commit is raising the RuntimeError pointing
out zsuper is not supported in blocks.

This uses a faulty heuristic that can be changed if we realize someone
somehow is doing something which breaks the heuristic.  We will raise
if we see a closure which is attached to a method call which is
define_method in the presence of existing in a method scope.  This means
if someone happens to have a zsuper in another method called define_method
in a def then we will not properly invoke the zsuper.

This also exposes an issue I think with our bytecode generation of
RaiseException which can be seen by running:

```ruby
  def test_define_method
    a = Object.new
    lambda {
      Class.new {
        define_method(:a) {super}
      }.new.a
    }.call
  end

  test_define_method
```

So a followup commit will come to address that and possibly also expanding
the above heuristic to define_singleton_method.

Interpreter was unwrapping and getting an exception object to throw
with throwExceptionIstr.  The JIT was only working with actual
exceptions.  This commit aligns the interpreter with the JIT and
the only two uses which would not work just become dynamic calls to
Kernel#raise.  This is fine because it does not complicate JIT by
making throwinstr more complicated and the dynamic calls only occur
extremely extremely rarely to raise errors.

The second fix is that define_method can sometimes convert itself
from being a closure to being a method.  This conversion did not
care whether zsuper was present or not.  We will now mark zsuper
in the closure scope and not perform this optimization in that case.

Reverted this logic.  The define_method and flip flop are stil dyncalls
but there is clearly more going on here.  Interesting too since the JIT
would crash if it received an IRubyObject instead of a Throwable.  It
must handle some of this differently in the JIT.