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. This update uses an explicit flag that says whether the user can go back, and this flag is passed to all views.

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
If you load the PP (same for ToS) page directly we don't use this template– we serve a pre-rendered page based on the template `/server/templates/pages/src/privacy.html`. So, this check is not necessary because it should only be used when you're navigating within the app. But now I can't remember why we pre-render PP/ToS...