What is the purpose of this pull request?

Provide Refinement#import_methods functionally to older versions to allow library authors to migrate to this safer way of re-using code in refinements.

See https://bugs.ruby-lang.org/issues/17429

What changes did you make? (overview)

• Added RubyNext::Core#import_methods API
• Added a rewriter to automatically pass binding to #import_methods and use RubyNext::Core.import_methods (see below).

Is there anything you'd like reviewers to focus on?

It's hardly possible to backport the #import_methods method using pure Ruby for several reasons:

• We want to allow imported methods to access their original dynamic scope (e.g., use constants defined in the imported module)
• We want to activate the current refinement for imported methods, i.e., the lexical scope should be kinda the same as for the current refinement.
• Ruby 2.6- doesn't support using Module refinements within refine do ... end—that makes it impossible to rely on adding a Module#import_methods refinement, we have to use our own helper method (RubyNext::Core.import_methods).

There is no way to manipulate the lexical scope in Ruby. Okay, there is—we can use bindings. And the only way to create something with bindings is to evaluate source code.

So, here is how our back port works:

• We extract the source of all imported module's own methods (and raise if there are some C methods or dynamically defined ones—this is the first limitation)
• We also "extract" constants (so they're accessible in the refinement)
• And we require a Binding object to be passed as the second argument; for that, we provide a rewriter (so, the Ruby Next transpiler does this for you).

Sounds too complex, right? That's okay for a transpiler 🙂 But I'm open for suggestions and any kind of critics.

Checklist

• I've added tests for this change
• I've added a Changelog entry
• I've updated a documentation/SUPPORTED_FEATURES.md