Enable pending cops – prepare for v3.0.0 release.

[bquorning]

As mentioned in the last release PR, it’s over a year since we released v2.0.0. Let’s enable all the pending cops and make a v3.0.0 release soon 🎉

---

Before submitting the PR make sure the following are checked:

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

[Darhazer]

I wouldn't rush to release 3.0 just to enable the cops.

At the very least, it would be a good time to bump the minimum rubocop requirement to whatever is the latest at the time of the release, so we can safely use whatever the internal modules it provides.

[pirj]

It makes sense to synchronize the 3.0 release with the RuboCop 2.0 release.

I was believing that RuboCop planned major releases every year. For the reason of not forcing users with more than a year worth of new pending cops being enabled at once. It's been 1.5 years since 1.0 was released.

It's unlikely, though, that RuboCop 2.0 will happen anytime soon.

My reasoning for doing a major version update is not to utilize the new rubocop APIs that we did with a minor 2.5.0 update, or dropping unsupported Ruby versions that we did with a minor 2.3.0 update. But just to split the burden of dealing with the many new cops.

I clearly understand that there's .rubocop_todo.yml, but from what I've seen in my practice, those "temporarily" disabled cops remain there forever (see e.g. ours).

If this sentiment doesn't resonate with your vision @Darhazer @bquorning, I have no hard feelings to closing this and postponing the release to follow the parent RuboCop release cycle.