- Remove support for Ruby 1.9, 2.0, and 2.1
- Remove support for Rails 3.1, 3.2, 4.0, and 4.1

These messages are used to tell users they can't access a page without
signing in, that their password is incorrect, etc. These are much closer
to error or alert states than notice.

`PasswordsController#url_after_create` was never called by our code.

These `respond_to` checks were added to support changing Rails API as
new versions of Rails were released. Now that we support 4.2 or newer,
we don't need them.

* Remove deprecated parameter handling
* Order actions more logically
* Update to double quotes

It is a best security practice for password reset token to expire after
some amount of time. In Clearance 1.x, this was not the case. A password
reset email could be used months after it was originally sent so long as
no other password reset was ever completed.

In this change, password resets expire after 15 minutes (configurable)
or after the user successfully changes their password in any manner
(whichever comes first).

The token, confusingly called `confirmation_token`, is no longer stored
in the database. Instead, we use `ActiveSupport::MessageVerifier` to
sign the token and validate it when it is used. The message verifier is
configurable in case developers want to use something else.

In a future refactoring, I'd like to introduce a layer between Clearance
and `ActiveSupport::MessageVerifier` to make the API a bit more pleasant
to use, but this is an exercise for a future PR. For instance, I'd
prefer that the Clearance abstraction generate and validate tokens only
by taking a user object (and using the Clearance configuration).

This cleans up some of the duplication of knowledge for how password
reset tokens are generated and allows us to move tests for the various
ways a reset token can be invalid into unit tests.

We were previously using the encrypted password as part of the signed
password reset token. Theoretically, emailing this token out could
expose the encrypted password to some adversary who would then be able
to do offline attacks against it.

This would likely not be very successful, but in an abundance of
caution, this change exposes an MD5'd version of the encrypted password
instead.