A few things:

* By putting this here, it causes a deprecation warning to be printed if `have` is called, but _not_ if `BuildIn::Have` is used directly.  While `have` is the main public API, it's possible that there may be extension gems that use the matcher class directly since they may have code in a context where they don't want to mixin `RSpec::Matchers` to gain access to the matcher API methods like `have`.  I'd prefer to see this warning moved into `BuiltIn::Have` so that it is printed regardless of if they use it directly or use this API.
* The `rspec-collection_matchers` gem is _not_ the only replacement.  User can also rewrite an expression like `expect(array).to have(10).items` to `expect(array.count).to eq(10)`.  I'd like for the deprecation warning to mention that they can either install your gem or change to that kind of expression.  Ideally, the deprecation warning would smartly print the exact expression they can use instead.   (taking into account owned vs unowned cases)...which suggests it'll have to be in the matcher, anyway, so that it can be a bit smarter.
* If users install your gem will they still get this deprecation warning?  It's important that they don't, because what we'll be telling users is "upgrade to 2.99, get your spec suite warning-free, then upgrade to 3.0" -- so it's important that when they do the right thing (e.g. switch to your gem), they no longer receive a warning.