UnboundMethod records caller's class, like `D` or `E` on the
following case:

```ruby
class C
  def foo = :foo
end

class D < C
end

class E < C
end

d = D.instance_method(:foo)
e = E.instance_method(:foo)
```

But `d` and `e` only refers `C#foo` so that UnboundMethod doesn't
record `D` or `E`. This behavior changes the following methods:

* `UnboundMethod#inspect` (doesn't show caller's class)
* `UnboundMethod#==` (`d == e` for example)

fix https://bugs.ruby-lang.org/issues/18798

* We need to resolve the zsuper method first, and then look the super
  method of that.

Because https://github.com/ruby/ruby/pull/5148 merged after Ruby 3.1.0 released.

https://github.com/ruby/actions/runs/4705986643?check_suite_focus=true#step:18:144
```
  1)
  Method#parameters adds * rest arg for "star" argument FAILED
  Expected [[:rest]] == [[:rest, :*]]
  to be truthy but was false
  /home/runner/work/actions/actions/snapshot-ruby_3_1/spec/ruby/core/method/parameters_spec.rb:228:in `block (3 levels) in <top (required)>'
  /home/runner/work/actions/actions/snapshot-ruby_3_1/spec/ruby/core/method/parameters_spec.rb:4:in `<top (required)>'

  2)
  Proc#parameters adds * rest arg for "star" argument FAILED
  Expected [[:req, :x], [:rest]] == [[:req, :x], [:rest, :*]]
  to be truthy but was false
  /home/runner/work/actions/actions/snapshot-ruby_3_1/spec/ruby/core/proc/parameters_spec.rb:85:in `block (3 levels) in <top (required)>'
  /home/runner/work/actions/actions/snapshot-ruby_3_1/spec/ruby/core/proc/parameters_spec.rb:3:in `<top (required)>'
```

This allows for the following syntax:

```ruby
def foo(*)
  bar(*)
end
def baz(**)
  quux(**)
end
```

This is a natural addition after the introduction of anonymous
block forwarding.  Anonymous rest and keyword rest arguments were
already supported in method parameters, this just allows them to
be used as arguments to other methods.  The same advantages of
anonymous block forwarding apply to rest and keyword rest argument
forwarding.

This has some minor changes to #parameters output.  Now, instead
of `[:rest], [:keyrest]`, you get `[:rest, :*], [:keyrest, :**]`.
These were already used for `...` forwarding, so I think it makes
it more consistent to include them in other cases.  If we want to
use `[:rest], [:keyrest]` in both cases, that is also possible.

I don't think the previous behavior of `[:rest], [:keyrest]` in
the non-... case and `[:rest, :*], [:keyrest, :**]` in the ...
case makes sense, but if we did want that behavior, we'll have to
make more substantial changes, such as using a different ID in the
... forwarding case.

Implements [Feature #18351]