Add new RSpec/Rails/NegationBeValid cop

[ydah]

Fix: #1660

---

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.

[pirj]

Nice, thank you!

[r7kamura]

Is this cop safe?
Since it is not guaranteed that the test target is an instance of ActiveModel::Validations, I think it may cause false-positives from an object that responds to only #invalid? (or only #valid?).

[ojab]

TBH quite a strange cop. As mentioned above, #[in]valid? is a pretty common method name for non-AR/AM objects, so it could braek something.
Also scope of the cop is just too small, AFAIU it's mostly about style of assertions where two methods exist and return opposite booleans, in that sense #valid? is no different from #odd?, i. e.

it { expect(1).to be_odd }
it { expect(1).not_to be_even }

Also using .not_to by default introducing inconsistencies, multiple expectations with .not_to, e. g.

expect(foo).not_to be_valid.and be_odd

are not supported and must be written as expect(foo).to be_invalid.and be_odd, so IMHO .to be_invalid is a more appropriate choice.