Method#unbind clones the method entry, preserving its defined_class.
For methods mixed in via include/extend, defined_class is an ICLASS,
causing UnboundMethod#== to return false when comparing against the
same method obtained via Module#instance_method.

Resolve ICLASS defined_class in method_eq.

[Bug #21873]

rb_obj_setup: do not copy RUBY_FL_SEEN_OBJ_ID

	[Bug #20250]

	We're seting up a new instance, so it never had an associated
	object_id.

	proc.c: get rid of `CLONESETUP`
	MIME-Version: 1.0
	Content-Type: text/plain; charset=UTF-8
	Content-Transfer-Encoding: 8bit

	[Bug #20253]

	All the way down to Ruby 1.9, `Proc`, `Method`, `UnboundMethod`
	and `Binding` always had their own specific clone and dup routine.

	This caused various discrepancies with how other objects behave
	on `dup` and `clone. [Bug #20250], [Bug #20253].

	This commit get rid of `CLONESETUP` and use the the same codepath
	as all other types, so ensure consistency.

	NB: It's still not accepting the `freeze` keyword argument on `clone`.

	Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>

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.