[Compatibility] Add Module#refinements

[itarato]

Source: #3039

Module#refinements has been added. [Feature #12737]

[itarato]

Copied from: https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/54198c7b97d3d353f7ac233e0360034b6e7b6cb6/entry/test/ruby/test_refinement.rb#L1751

[eregon]

Needs a TruffleBoundary (on the specialization to keep it simple) for the .values() and .toArray()

[itarato]

Added.

[eregon]

An MRI test is failing (we should try to run those on GitHub Actions):

  1) Failure:
TestRefinement#test_refinements [/b/b/e/main/test/mri/tests/ruby/test_refinement.rb:1850]:
<[#<refinement:Integer@#<Module:0x115a3b8>>,
 #<refinement:String@#<Module:0x115a3b8>>]> expected but was
<[#<refinement:String@#<Module:0x115a3b8>>,
 #<refinement:Integer@#<Module:0x115a3b8>>]>.

[itarato]

An MRI test is failing (we should try to run those on GitHub Actions):

  1) Failure:
TestRefinement#test_refinements [/b/b/e/main/test/mri/tests/ruby/test_refinement.rb:1850]:
<[#<refinement:Integer@#<Module:0x115a3b8>>,
 #<refinement:String@#<Module:0x115a3b8>>]> expected but was
<[#<refinement:String@#<Module:0x115a3b8>>,
 #<refinement:Integer@#<Module:0x115a3b8>>]>.

@eregon To respect ordering I switched to linked hash map, which has I believe has a minor disadvantage on create (in time) as well as I believe using atomicity via Collections.synchronizedMap is slighly slower than ConcurrentHashMap. Would we consider this acceptable or should we look for alternatives?

[eregon]

There are two problems with that:

• Collections.synchronizedMap() does not allow parallel lookups. And so it means method lookup in different threads would cause contention if there are refinements active in the scope where the lookup happens.
• Collections.synchronizedMap() does not synchronize iterables like for (var entry : map.entrySet()), which is then incorrect synchronization and causes all sorts of problems.

I think the test should allow both, ordering there seems artificial and unnecessary, it will not affect method lookup semantics, as anyway it's a single refinement module per class/module being refined inside a namespace module.
Could you either tag the MRI test or not add it in this PR? There is already a spec doing the appropriate check.

[itarato]

There are two problems with that:

* `Collections.synchronizedMap()` does not allow parallel lookups. And so it means method lookup in different threads would cause contention if there are refinements active in the scope where the lookup happens.

* `Collections.synchronizedMap()` does not synchronize iterables like `for (var entry : map.entrySet())`, which is then incorrect synchronization and causes all sorts of problems.

I think the test should allow both, ordering there seems artificial and unnecessary, it will not affect method lookup semantics, as anyway it's a single refinement module per class/module being refined inside a namespace module. Could you either tag the MRI test or not add it in this PR? There is already a spec doing the appropriate check.

@eregon Removed that change and tagged the MRI test.