Lock rubocop-capybara dependency to < 3.0

We've noticed that if we don't lock it, a release of rubocop-capybara
3.0 would still install along with rubocop-rspec 2.18.0.
Also, Bundler may prefer installing an older rubocop-rspec version
(2.18.0) and rubocop-capybara 3.0 instead of a newer 2.18+ rubocop-rspec with
rubocop-capybara 2.x.

See
eed7439#r96342863
for details.

In a while after this is released, we plan to yank the release 2.18.0 to
prevent suddenly enabling Capybara cops from rubocop-capybara 3.0.

We acknowledge that yanking may cause CI of projects that locked (via
Gemfile.lock) their rubocop-rspec dependency to 2.18.0 would break on
the `bundle install` stage.
To mitigate that, we give some time to update to an even newer 2.18+
version before yanking 2.18.0

CHANGELOG.md

@@ -2,9 +2,11 @@
 
 ## Master (Unreleased)
 
+- Add `rubocop-capybara` version constraint to prevent sudden cop enabling when it hits 3.0. ([@pirj])
+
 ## 2.18.0 (2023-01-16)
 
-- Extract Capybara cops to a separate repository. ([@pirj])
+- Extract Capybara cops to a separate repository, [`rubocop-capybara`](https://github.com/rubocop/rubocop-capybara). The `rubocop-capybara` repository is a dependency of `rubocop-rspec` and the Capybara cops are aliased (`RSpec/Capybara/Foo` == `Capybara/Foo`) until v3.0 is released, so the change will be invisible to users until then. ([@pirj])
 
 ## 2.17.1 (2023-01-16)
 

rubocop-rspec.gemspec

@@ -38,5 +38,5 @@ Gem::Specification.new do |spec|
   }
 
   spec.add_runtime_dependency 'rubocop', '~> 1.33'
-  spec.add_runtime_dependency 'rubocop-capybara'
+  spec.add_runtime_dependency 'rubocop-capybara', '~> 2.17'
 end