feat(client): Add support for `preVerifyToken`.

`preVerifyToken` is sent by trusted RPs to indicate that a user is already verified. The Auth Server
then does a dance with the trusted RP to determine whether to create an account for the user without
the need to verify their email address. If the user is pre-verified, the signup flow completes at the
`/signup_complete` screen. If the pre-verification fails, the user is still requried to verify their
email address as is currently done.

This PR also introduces the concept of a `Relier` model. A Relier is a model
that represents an RP and information about/from the RP.

fixes #1540

Items that still need to be completed:
* [x] - Update the fxa-js-client to pass along `preVerifyToken` - See https://github.com/mozilla/fxa-js-client/pull/127
* [x] - Update the fxa-auth-server to handle `preVerifyToken` - See https://github.com/mozilla/fxa-auth-server/issues/780
* [x] - Update 123done to generate `preVerifyToken`s & rip that cruft out of here. See https://github.com/mozilla/123done/pull/114
* [x] - Update the auth-server's default local.json config to allow `preVerifyToken` from 123done. See https://github.com/mozilla/fxa-auth-server/pull/794
* [x] - Update the functional test to make use of 123done instead of generating tokens locally.
* [x] - Update the /oauth/signup page to redirect to the RP if preverification was successful.
At the risk of being pedantic: should we use an `_` here if we intend for subclasses to use this function. Likely we mean the `_` prefix to represent anything that's not intended to be public (therefore what would be private *or* protected in other langs), but just making sure... :smile:.