Spec out the different supported response types.

:frowning: per https://github.com/rspec/rspec-rails/blob/52de86da8d99c4749a143e18423f956f9c57d424/features/support/capybara.rb#L2-L5

> We are caught in a weird situation here. rspec-rails supports 1.8.7
> and above, but capybara beyond a certain version only supports 1.9.3
> and above.  On 1.8.7 and 1.9.2, we run most of the rspec-rails test
> suite but leave out parts that require capybara.

Digging into this it seems that after Capybara 2.0.3 [support for Ruby
1.9.2 was dropped](https://github.com/jnicklas/capybara/issues/1049).
Thus, the feature spec covering this never ran.

From what I understand, rspec-rails 2.12+ moved to Capybara 2.0 for
feature specs; and no longer uses is for request specs.

This means for 1.8.7, this will only apply to the case where request
specs are using Capybara < 2.0. This version still defines the same
public API, so I guess we still need to support this edge condition.
Matchers should return true / false from matches?

To properly implement the matcher protocol, only `true` and `false`
should be valid values to return from `matches?`.
Use a helpful failure message on bad response type
Use api private tag.
Shadow variable intent in the name.
Add custom matcher descriptions.
Memoize intermediate computations.