updating feature docs to reflect capybara 2.3.0 dependency

change made in 8254ddc10c8e34912300ca2c8df275cc5132d1ba
Even if they do backport it, this needs to remain `2.2.0` here -- getting an error at load time due to a version change here after upgrading to RSpec 3.1 when your test suite was green on 3.0 certainly counts as a breaking change.  We can (and should) recommend newer versions in our documentation but we can't give the user an error for a version of capybara that worked (even though it had warnings) against RSpec 3.0.



> Btw, the changes from capybara 2.2.0 to 2.3.0 doesn't look big and I don't think any user will have problems updating (I think that the update will be less harmeful and will raise less questions then the deprecation warnings).

Consider the case where the user is using a gem that has a dependency on capybara `2.2.0` and that does not yet have a release out that allows `2.3.0`...it won't be simple for the user to upgrade.

So, to summarize: we should very much encourage users to upgrade to 2.3.0 but we can't fail if they are still on 2.2.0 given SemVer and the fact that RSpec 3.0.0 allowed 2.2.0.