feat: support correcting *_in_delta assertions in RSpec/Rails/MinitestAssertions

[G-Rath]

This is branched off #1790, showing how easy it is to now add a new assertion matcher - until the prior PR is merged, the last commit of this PR should be looked at for review.

related to rubocop/rubocop-rspec_rails#7

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have created a new cop:

• Added the new cop to config/default.yml.
• The cop is configured as Enabled: pending in config/default.yml.
• The cop is configured as Enabled: true in .rubocop.yml.
• The cop documents examples of good and bad code.
• The tests assert both that bad code is reported and that good code is not reported.
• Set VersionAdded: "<<next>>" in default/config.yml.

If you have modified an existing cop's configuration options:

• Set VersionChanged: "<<next>>" in config/default.yml.

[pirj]

Message can be a proc:

# File lib/minitest/unit.rb, line 196
    def assert test, msg = nil
      msg ||= "Failed assertion, no message given."
      self._assertions += 1
      unless test then
        msg = msg.call if Proc === msg
        raise MiniTest::Assertion, msg
      end
      true
    end
    ```

[G-Rath]

That's not unique to this though, and none of our code depends on that - we're just copying the source code as is (you might be mentioning this because we're doing !failure_message.empty? for this assertion, but that is checking against an array which contains the matched nodes).

We should have tests for this but since it applies for every assertion we currently have I'll do it in a dedicated PR

[pirj]

I’m most concerned (see my earlier comments below), is that we assume that the message (str/sym) can be passed as the third argument, and in this case, skip matching. But this would be incorrect for Minitest.
My point is to disregard the type, and always consider the third argument to be the delta (optional), and the fourth - the message (optional, no type constraints.

I agree that we’d better investigate proc messages in a separate pr. Wondering if RSpec provides a lazily evaluated failure message and we could autocorrect those.
If it can’t - we need to skip autocorrection.

[pirj]

Good news that RSpec does seem to support proc failure messages.. I would still double check this.

[pirj]

Thank you! What a streak!