fix(client): Show the back button for reset_password, even if an email is on the URL query string. Generalize whether the "back" button should be shown.

In `/reset_password`, the `email` query parameter was used as a proxy to indicate whether the user has directly browsed to the page. If the user directly browses to the page, the "back" button should not be shown.

Proxy checks are never a great idea. Instead, use an explicit flag that says whether the user can go back.

Logic:
* The first FxA view displayed cannot go back.
* Subsequent views can go back.

All views that have a back button only show the back button if the user can go back. If the user directly visits a page with a back button, the button will not be shown.

Another considered option:
Check if window.history.length > 1. If so, the user can go back. This was strange if users visited a page with a back button from an external site. A user could click "back" and go back to the previous site, not really expected.

Other work:
* Ensure there are functional tests for the existence/non-existence of the back button on pages that have them.
* Extract the delete_account related tests from settings into its own module.

fixes #1917
Merge pull request #1927 from mozilla/issue-1917-back-in-reset-password

fix(client): Show the back button for reset_password, even if an email is on the URL query string. Generalize whether the "back" button should be shown.