Fix false-positives that non Rails formats are offended on Rails/ToSWithArgument

[r7kamura]

We had Rails/ToSWithArgument Cop to replace to_s with to_fs where Rails' extended functionality is used, but there are frequent false-positives where to_s is used with non Rails extended formats like value.to_s(2) (Integer#to_s).

To prevent this, it would be better to check its 1st argument so that only cases that appear to use Rails-extended functionality are offended.

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.
• If this is a new cop, consider making a corresponding update to the Rails Style Guide.

[r7kamura]

Let me provide a little more background.

To prepare to set config.active_support.disable_to_s_conversion = true (which is also set by load_defaults 7.0), I've tested this Cop against the source code of all the Gems that my Rails app depends on, and I noticed that there were so many false-positives. I ended up inspecting 20000+ Ruby files and found that 2 files still used the Rails extended to_s 😨, and there are 200+ false-positives about Integer#to_s.

This is why I decided to add this fix.

[koic]

This is unnecessary as it premises a dependency.

[r7kamura]

Thanks, I'll remove this line.

I was wondering about this point as well because this would not only be a matter of necessity, but rather a matter of policy as to who will play the coordinating role, like the contrast between choreography vs. orchestration. I understand that the policy here is to let lib/rubocop.rb in rubocop gem coordinate the dependencies 👌