[Bug #20868] Fix Method#hash to not change after compaction

	The hash value of a Method must remain constant after a compaction, otherwise
	it may not work as the key in a hash table.

	For example:

	    def a; end

	    # Need this method here because otherwise the iseq may be on the C stack
	    # which would get pinned and not move during compaction
	    def get_hash
	      method(:a).hash
	    end

	    puts get_hash # => 2993401401091578131

	    GC.verify_compaction_references(expand_heap: true, toward: :empty)

	    puts get_hash # => -2162775864511574135

	[Bug #20342] Consider wrapped load in `main` methods

	[Bug #19896]

	fix memory leak in vm_method

	This introduces a unified reference_count to clarify who is referencing a method.
	This also allows us to treat the refinement method as the def owner since it counts itself as a reference

	Co-authored-by: Peter Zhu <peter@peterzhu.ca>
	---
	 gc.c                     |   4 +-
	 method.h                 |   6 +--
	 rjit_c.rb                |   6 +--
	 test/ruby/test_module.rb |   4 +-
	 vm_insnhelper.c          |   2 +-
	 vm_method.c              | 105 +++++++++++++++++++----------------------------
	 6 files changed, 54 insertions(+), 73 deletions(-)

	Fix memory leak in complemented method entries

	[Bug #19894]

	When a copy of a complemented method entry is created, there are two
	issues:

	1. IMEMO_FL_USER3 is not copied, so the complemented status is not
	   copied over.
	2. In rb_method_entry_clone we increment both alias_count and
	   complemented_count. However, when we free the method entry in
	   rb_method_definition_release, we only decrement one of the two
	   counters, resulting in the rb_method_definition_t being leaked.

	Co-authored-by: Adam Hess <adamhess1991@gmail.com>
	---
	 method.h                 |  5 +++--
	 test/ruby/test_module.rb | 29 +++++++++++++++++++++++++++++
	 vm_method.c              |  8 +++++---
	 3 files changed, 37 insertions(+), 5 deletions(-)

	Fix write barrier order for `klass` to `cme` edge

	Previously, the following crashes with
	`CFLAGS=-DRGENGC_CHECK_MODE=2 -DRUBY_DEBUG=1 -fno-inline`:

	    $ ./miniruby -e 'GC.stress = true; Marshal.dump({})'

	It crashes with a write barrier (WB) miss assertion on an edge from the
	`Hash` class object to a newly allocated negative method entry.

	This is due to usages of vm_ccs_create() running the WB too early,
	before the method entry is inserted into the cc table, so before the
	reference edge is established. The insertion can trigger GC and promote
	the class object, so running the WB after the insertion is necessary.
	Move the insertion into vm_ccs_create() and run the WB after the
	insertion.

	Discovered on CI:
	http://ci.rvm.jp/results/trunk-asserts@ruby-sp2-docker/4391770
	---
	 vm_eval.c       |  3 +--
	 vm_insnhelper.c | 10 ++++++----
	 vm_method.c     |  3 +--
	 3 files changed, 8 insertions(+), 8 deletions(-)

I noticed this while running test_yjit with --mjit-call-threshold=1, 
which redefines `Integer#<`. When Ruby is monkey-patched, 
MJIT itself could be broken.

Similarly, Ruby scripts could break MJIT in many different ways. I
prepared the same set of hooks as YJIT so that we could possibly
override it and disable it on those moments. Every constant under
RubyVM::MJIT is private and thus it's an unsupported behavior though.

Previously, the frozen check happened on `RCLASS_ORIGIN(self)`, which
can return an iclass. The frozen check is supposed to respond to objects
that users can call methods on while iclasses are hidden from users.
Other mutation methods like Module#{define_method,alias_method,public}
don't do this. Check frozen status on the module itself.

Fixes [Bug #19164] and [Bug #19166].

Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>

Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>

Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>