Prefer require_relative for internal requires

[tagliala]

As a side note, this change has been approved here by @deivid-rodriguez which is familiar with this issue: activeadmin/arbre#622

---

require_relative is preferred over require for files within the same
project because it uses paths relative to the current file, making code
more portable and less dependent on the load path.

This change updates internal requires to use require_relative for
consistency, performance, and improved portability.

Ref:

• Prefer require_relative for internal requires ruby/psych#522
• Prefer require_relative, it's a little bit faster. ruby/logger#20
• Prefer require_relative ruby/rdoc#658
• Benchmarks: are memowise results reliable? #349
• Prefer require_relative rubocop/rubocop#8748

---

Before merging:

• Copy the table printed at the end of the latest benchmark results into the README.md and update this PR
• If this change merits an update to CHANGELOG.md, add an entry following Keep a Changelog guidelines with semantic versioning

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (ac1231e) to head (c8c11f6).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #350   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            2         2           
  Lines          190       190           
  Branches        90        90           
=========================================
  Hits           190       190           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pboling]

LGTM

[JacobEvelyn]

Would you mind actually adding something to the CHANGELOG.md for this? Maybe like:

**Gem enhancements:**

- Changed internal `require`s to `require_relative` to make code less dependent on the load path [[#350](https://github.com/panorama-ed/memo_wise/pull/350)]

if you fixup that change into the same commit I'll approve and merge!

see comment

[tagliala]

@JacobEvelyn done and force pushed in the same commit

As a side note, for some extreme use cases, this can be considered a breaking change

Ref: varvet/pundit#831 (comment)

[pboling]

It is a potential breaking change for a use case that isn't actually a feature or intended. What he describes is a way to break the gem on purpose with knowledge of the source, so that you can hack a library in a very strange way. It is an interesting thought experiment. Several people have now responded to him on the RuboCop discussion.

IMO it would be extreme to consider this a breaking change, especially since it fixes a real use case, which is benchmarking as this gem does.

[JacobEvelyn]

Yes I agree with both of these that this should not be considered a breaking change.