Account details page ux

Proposal for an account details page in terms of the navigation/UX.

This MR just sketches out the outline of an account details page with main navigation elements (buttons) in place and 'working'.

Proposed UX

The MR is intended to demo the proposed UX for the details page in a rough first draft/outline form. Below follows some accompanying notes on what that UX is supposed to be and why, and also what else is anticipated but (deliberately) not yet implemented in the MR.

Page hierarchy

1. The details page represents a deeper level of navigation, and is therefore only ever shown in addition to the main page.

Navigating to the page

1. The user may enter the details page by clicking on an account from the main page (overview list)
2. Or the user may successfully add an account from the main page, which will open the details page of the newly created account on completion of the "add" action.

Navigation on the page: modality

The page itself implements a kind of modality with three modes. Modality allows to avoid deeply 'nested' navigation elements, keeping the return path short and also minimising the number of potentially 'jarring' transitions. Modality is warranted here because the various modes only reflect a different way of interacting with the same basic content (forms fields with account details). There are three modes:

1. A 'hide' mode, which is the default. In this mode sensitive account properties such as the token secret should not be openly visible in the UI. (Currently this is not yet implemented fully in the controls). This would also imply to QR code visualisation of the token configuration. (The QR code would encode the token parameters as a URL, including the secret -- hence it would be sensitive information).
2. A 'show' mode which merely toggles the default visibility of sensitive information to openly show their contents.
3. An 'edit' mode which allows the user to edit the OTP parameters for the account. In this mode the toggling between hide and show is irrelevant and corresponding actions are not shown/enabled on the page. The user dismisses edit mode through "Apply" and returns to the page in 'hide' mode.

Other actions

1. Refresh: in both show and hide modes there is an additional refresh action to manually refresh the token value (and advance the counter in the case of HOTP). This is equivalent to the existing refresh functionality on the main page. It is implemented on this page as well because on mobile it is expected the main page will not be visible.

Anticipated actions (not implemented in this MR)

1. A "Delete" action in 'edit' mode, which would delete the account.
2. A "Cancel" action in 'edit' mode. This would need decoupling/rewriting the way accounts are currently managed because right now everything is instant-apply without a way to undo modifications in the UI.
3. A page drawer containing "Delete", "Copy" actions. Delete would be the same as for 'edit' mode, "Copy" would allow the user to copy the token parameters as a URL and/or QR code to the clipboard.

A note on "delete": it should not be a 'top level' action on the page UI since accidental account removal would be very hard to recover from (fairly technical, and typically sites only hold your hand during initial 2fa setup -- afterwards good luck finding info buried in obscure settings UIs...).

Similarly, any "Copy" or "Share" action type should also not be a 'top level' action on the page, to help the user avoid accidentally leaking their account/token info. Hiding it in a drawer should help the user to avoid mistaken clicks.

Other (deliberate) shortcomings/notes

1. Token value and QR code UI is not implemented on the page in this MR.
2. Account names should probably not be editable, especially not if we ever want to show and sort by account names in the main page token/account overview list. In any case editing account names is not implemented as part of this MR.