We can't blindly get the current object's class's superclass
because the object's class may be multiple descendants below the
Set class, causing super calls to super back into a lower point
in the hierarchy. This is the cause of jruby#6958.

The fix here is to request a frame be pushed for Set#init_dup and
init_clone so that we can redispatch from the proper point in the
hierarchy. This also properly uses SuperCallSite, passing in the
class from which to super. The original code was flawed in two
ways:

* It always acquired the superclass via object.class.superclass,
  which does not work for a two-deep descendant of Set.
* It passed the superclass in for the frame class, which allowed
  the flawed logic to work for one level deep. It is broken for
  two levels deep or no levels deep because it passes the wrong
  frame class.

This was not found during testing of jruby#6910 because the original
example only has one descendant.

We can't blindly get the current object's class's superclass
because the object's class may be multiple descendants below the
Set class, causing super calls to super back into a lower point
in the hierarchy. This is the cause of jruby#6958.

The fix here is to request a frame be pushed for Set#init_dup and
init_clone so that we can redispatch from the proper point in the
hierarchy. This also properly uses SuperCallSite, passing in the
class from which to super. The original code was flawed in two
ways:

* It always acquired the superclass via object.class.superclass,
  which does not work for a two-deep descendant of Set.
* It passed the superclass in for the frame class, which allowed
  the flawed logic to work for one level deep. It is broken for
  two levels deep or no levels deep because it passes the wrong
  frame class.

This was not found during testing of jruby#6910 because the original
example only has one descendant.