* For the buttons, use id's instead of classes.
* Focus the "yes" button when the screen is shown.

issue #1582

Make users who have not yet set their password by time they reach the landing page set their password.

issue #1592

when the server returns a 413 error for posting of interaction data, clear the data from local storage - issue #1567

issue #1581

insert a setTimeout between two main phases of assertion generation to prevent unresponsive script warnings in IE8 - issue #1575

* css/style.css - where relevant and opacity's are used, use filters for IE6 and IE7.
* shared/storage.js - when clearing localStorage if the user is not authenticated, call removeItem for the emails.  The call to JSON.stringify was blowing up.

issue #1529

Partial fix IE6 and IE7 blowing up on main site.  These browsers do not have Array.prototype.indexOf

issue #1552

Replace the removed `delete storage.interactionData` with localStorage.removeItem("interactionData") to avoid IE8 exceptions.

Consolidating exception logging, removing delete which can cause problems in Chrome. [Partially?] Fixes Issue#1546

Updating documentation in cookiesEnabled to include Android 4.0 default browser still passing the cookiesEnabled check with cookiesDisabled.

close #1542

added conformance tests.

tests should now pass
updated to jwcrypto that has proper callback delay guarantees and removed unnecessary setTimeouts

Updated all calls to jwcrypto to use the more intuitive API. Fixed a front-end test that was failing due to true asynchronicity of jwcrypto.

* If the controller's "continuation" option is specified, start saving data immediately to localStorage.
* in start.js, look for CREATE_EMAIL and ADD_EMAIL on the window.location.hash. If this exists, the dialog session is a continuation.
* Add some more tests.

Other notable changes:
* Send old interaction data irregardless of whether the current dialog session is collecting data.
* Because of this above change, simplified storage regarding data.
* Make sure when sampling is enabled, data is saved.
* Make sure when sampling is disabled, data is not saved.
* Added tests to test expected flow.

To test:
* Make sure verification works if a valid token is given.
* Make sure error message is displayed if invalid token is given.
* Make sure error message is displayed if no token is given.

issue #1495

* Create a list of pages where the cookie check should be run.

issue #1514

issue #1521

don't require that a user re-enter their password in dialog after email verification in a different browser.  Because the user just typed their password, attempt to authenticate them in the verification originating browser via the API.  If that works, then automatically log them in

* user.js: Update verifyEmail and verifyUser to take a password.
* network.js: Update completeEmailRegistration and completeUserRegistration to take a password.
* Replace verify_email_address.js and add_email_address.js with a single verify_secondary_address.js to reduce duplication.
* Update the templates.
* Bring back verify_email_address and add_email_address templates, but remove the verify password field.
* To dom-jquery, add show, hide functions.

modify interaction_data api to always return a quick success, update hub.js to add an .all() function that subscribes to all published events, interaction_data module now adds all published events to event stream

implement frontend interaction_data mechanisms, still require tests, event_stream population, and reduced UA information parsing

* /wsapi/complete_email_addition no longer has to bcrypt the password, so the previously mentioned race condition should be a thing of the past.
* in pages/start.js, signUp is now a module so it has to be started.
* in controllers/actions.js doEmailConfirmed is no longer an action and is no longer needed.

* Move #thisIsNotMe button handler from the page_module to pick_email.
* Remove extra tests for the authenticate controller.
* use the alias for BrowserID.User in helpers.js
* Add password fields to the forgot page.

* helpers.addEmail triggers either "primary_user" or "add_email_submit_with_secondary"
* Add states to the stage machine to handle add_email_submit_with_secondary to either set a password or stage the user.
* Add two helper functions in storage.js, addPrimaryEmail and addSecondaryEmail

* Verify the user without checking for passwords on the verification pages.
* Update /wsapi/stage_email to take a password.
* Remove the password fields of the verify page forms.
* Set the password when adding an email address.

* Remove the forgot_password controller, templates, tests, etc.
* Update authenticate to trigger "new_user" with rehydration info
* Update set_password to be able to handle resetting passwords as well.
* Update the state machine to handle password setting or resetting.

* Update set password to handle either initial password set or a password reset
* Update network/user.js to handle passwords when creating new users or resetting passwords.

Update remaining reset_password test to deal with new flow when the user confirms the address.