Document the `have_http_status` matcher.

Outline the intended use cases for the `have_http_status` matcher:

- It is designed to work of "response" objects
- It should work with controller, request, and feature specs
- It allows checking against:
  - Specific numeric status codes
  - Any of the Rails provided symbolic names for status codes
  - General status code categories
Create `have_http_status` matcher.

The matchers passes if the provided actual `response`, or Capybara
`page`, has a matching HTTP status code. The following symbolic status
codes are allowed:

  - `Rack::Utils::SYMBOL_TO_STATUS_CODE`
  - One of the defined `ActionDispatch::TestResponse` aliases:
    - `:error`
    - `:missing`
    - `:redirect`
    - `:success`

The inspiration for this matcher comes directly from Rails' `assert_response`:

  https://github.com/rails/rails/blob/ca200378/actionpack/lib/action_dispatch/testing/assertions/response.rb#L22-L38

Thank you to all the Rails devs who did the heavy lifting on
`assert_response`!
Add changelog note.
Note `have_http_status` matcher in README.
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.
Handle matrix configs which don't have Capybara.
Update feature to be valid Ruby.
Merge pull request #987 from rspec/response-status-matcher

Add response status matcher