Implement a Great User Experience as email providers implement persona

*NOTE:*  This pull request is not ready for merge, but is hungry for review.

In order to turn on bigtent and to prepare for popular email providers to implement persona support, these changes attempt to make UX great for users with email addresses that gain (or loose) "primary" persona support.  Language and screens are added, and more.

## 10k Foot Overview

This change-set:

  * Introduces new screens and new language for all transition cases (still in progress) to help users understand what's going on.
  * Adds mechanisms to allow for zero-downtime switch flipping for primaries
  * Removes much state from the frontend and letting the server manage it

## API Changes (@francois and @zaach, please review?)

  * list_emails now returns a list of emails without any additional information
  * address_info now returns a "state" for emails, that tells the frontend what flow it should display to the user
  * address_info now returns the current issuer for the domain
  * update_password is now callable by a `assertion` authenticated user (does not require pw auth)
  * used_address_as_primary is added, which is a means for the frontend to tell the backend that the user has used an address as a primary (causing a transition UX to not be displayed subsequently)
  * session_context now has a `has_password` key which the frontend can use to know definitively whether the user has set a password

## Front End Work: (@shane-tomlinson, please review?)

  * several new screens added
  * we no longer store email `type` nor `verified` in local storage, everywhere where we were using these from local storage, we are now getting them from address_info
  * address_info is called Every Time the user picks an email address, which is the point where we determine what state to transition to
  * everywhere where we determined if the user has a password by looking for a local secondary address, we now defer to `session_context`'s `has_password` property

## Database Changes (@warner and @gene1wood, please review?)

  * `lastUsedAs` field is added, `type` field is removed.  they both contain either `primary` or `secondary`.  the difference is for `type` it was not expected to change, while `lastUsedAs` is the last form the email address was in when the user used it.  `lastUsedAs` may be seeded from `type` for the purposes of database migration
  * `idp` table added.  This holds recently seen idps and a timestamp of when they were last seen.  This allows us to consider an idp broken when they stop serving `.well-known` without an explicit signal.

## Security Questions (@warner and @francois please review?)

  * new information leaks in `address_info`
  * loosing of require auth level in `update_password`

## Spec changes (@callahad and @warner and @benadida, please review?)

  * new parsing of .well-known documents
  * addition of `disabled` property in these documents, which is a signal to the *implementation* that it should fall back to secondary and the primary wishes to opt out
  * new SHOULD behavior of verifier: it should verify assertions whenever `public-key` is defined, but ignore `disabled`