refactor(client): No longer call fxa-js-client->signIn after signUp. signUp does everything it needs to do.

fixes #1840
Use the newest fxa-js-client which contains the `unwrapBKey` functionality needed in signUp.
fix(client): Allow Fx18 to use the iframe flow.

Fx18 had two problems:
1) anchor.origin is not available and must be built from anchor.protocol and anchor.host.
2) anchor.protocol and anchor.host are only updated if the anchor's href is set via `anchor.setAttribute(href, ...`.

fixes #1969
cleanup(test): Use the `fillOutSignUp` functional helper to reduce duplication.
Merge pull request #1970 from mozilla/issue-1969-iframe-fx18

fix(client): Allow Fx18 to use the iframe flow.
Merge pull request #1963 from mozilla/issue-1840-no-signin-after-signup

refactor(client): No longer call fxa-js-client->signIn after signUp. signUp does everything it needs to do.
refactor(client): Move interTabCommunication out of fxa-client into the views that need it.

interTabCommunication crept into fxa-client. The interTabCommunication functionality is only really necessary in complete_reset_password, so it has been moved there.

fixes #1807
Merge pull request #1966 from mozilla/issue-1807-inter-tab-channel

refactor(client): Move interTabCommunication out of fxa-client into the views that need it.

rebased, thanks @zaach!

r=zaach
fix(server): Allow the 500 and 503 pages to be iframed.

fixes #1978
Merge pull request #1979 from mozilla/issue-1978-iframe-error-pages

fix(server): Allow the 500 and 503 pages to be iframed.
Merge pull request #1971 from mozilla/cleanup-sign_up-functional-test

cleanup(test): Use the `fillOutSignUp` functional helper to reduce duplication.
fix(signin): pass account data to broker instead of using currentUser

Fixes #1973.
refactor(views): avoid use of getCurrentUser on non-settings pages

This is a follow up to #1973 and the broader point that ckarlof makes:
> More generally, I don't think getCurrentAccount should be used except to initialize UI state. After the user has initiated a flow for an account, we should be passing an Account object with the account context to the broker as needed. This way, it would be less likely that the Broker uses the wrong account (i.e., not the one the user selected) mid-flow. This might involve a significant refactor (although maybe not, because we don't use the user that much in the broker anyway), but it seems worth it to avoid these types of bugs in the future.