fix(account): filter account.toJSON
feat(client): An Fx Sync relier can specify `customizeSync=true` to force the Customize Sync checkbox to be checked.

fixes #1954
Add the `importBooleanSearchParam` function to the search-param mixin.
refactor(client): Simplify the error handling code.

* Rename `code` to `errno` to be consistent with the backend.
* Use a single hash called ERRORS for each namespace. The has contains both `errno` and `message`
* Extract `errors.js` from logic that was in `auth-errors.js`
* Extract `profile-errors.js` from logic in `profile-client.js`

fixes #1508
fix(client): OAuth/redirect users who paste the verification link into the original tab should be redirected to the RP.

Save a bit to sessionStorage whenever the user signs up or initiates a password reset. When the verification tab opens, it looks for this bit. If the bit is set, that means the user overwrote the signup/reset password tab with the verification tab and the user should redirect to the RP when the OAuth flow completes. If the bit is not set, this is either another tab or another browser, and the user should *not* go back to the RP.

fixes #1816
fix(docs): update AUTHORS list

Closes #1981
Merge pull request #1976 from mozilla/issue-1508-refactor-errors

refactor(client): Simplify the error handling code.
Merge pull request #1990 from mozilla/issue-1975-poluted-json

fix(account): filter account.toJSON
The fx-desktop relier swallows the TypeError thrown by importBooleanSearchParam until we have startup error handling nailed down.
Merge pull request #1962 from mozilla/issue-1954-control-sync-checkbox

feat(client): An Fx Sync relier can specify `customizeSync=true` to force the Customize Sync checkbox to be checked.
Merge pull request #1947 from mozilla/issue-1816-redirect-verify-same-tab

fix(client): OAuth/redirect users who paste the verification link into the original tab should be redirected to the RP. r=vladikoff
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.
fix(signin): set the current account after logging in with cached sync account
refactor(account): no more accountData and less usage of currentAccount