It looks like this will print a deprecation warning for each use of a custom matcher that receives a single argument.  However, in the vast majority of cases it will work fine without any changes.  (Plus there's nothing the user can do about this).

The problem isn't custom matchers that receive a single argument; the problem is custom matchers that access the `expected` attribute and expect it to be an array when it will be a single value on rspec 3.  So, I think the deprecation warning needs to go in the definition of the `expected` method as that's the real case we care about.

We need to provide a way for users to deal with this during the upgrade process as well.  (Giving them a warning, without providing a solution, does nothing).  I'm not sure what's best here, but how about adding an `expected_array` attribute that contains the original array and will always be an array in 2.99 and 3.x?  Then the deprecation warning can tell them to switch to that.  We'll have to add it to 3.0 though.

Another complexity: we need to ensure the deprecation isn't issued when we access `expected` (e.g. from the diffing).  Maybe as a temporary 2.99 measure the solution is to update the spot where we access `expected` to access `expected_array` if the method is there.