Add plausible deniability to vaults

**What problem are you trying to solve?**

Someone walks up to you and forces you to log in to MM. "I forgot the password" doesn't quite make it.

**Describe the solution you'd like**

Have an option in the vault to set up a secondary vault, tied to the primary one. This requires you to define a password to the secondary vault, one which is different from the primary vault's password. Upon logging in with the secondary password, the secondary vault will open, which will be indistinguishable in function from the primary one and enjoys the same permanence and customizability as the primary one, but will have different addresses and potentially different external accounts and token additions.

This is just an idea and raises many hard questions to which I don't know the answers. Here's an unstructured stream of the problems.

* To implement something like this, we may need fancier crypto.
* We need to redefine the structure of how vaults are stored.
* We may need/want to convert vaults with the old structure to the new one if something like this becomes implemented. How do we do that safely?
* We need to make sure that vaults with and vaults without a secondary vault are indistinguishable from the outside.
* We need to make sure that primary and secondary vaults are indistinguishable from the inside.
* Should the secondary be derived deterministically from the primary, deterministically from the new password, or just purely randomly?
* How do you check that the two passwords are not the same?
* Once you're logged into the primary, should you be able to detect that there's a secondary? If yes, should you be able to modify it from there?
* What should happen if you already have a secondary, but you define a new secondary?
* What should happen if we define a secondary while logged into the secondary?
* If we allow a recursive chain of subvaults or multiple secondary vaults (may be desirable), how do we ensure indistinguishability from the outside?
* Many other questions I haven't thought of.

No files, tests, or entry points are named. Begin by mapping the existing vault storage and cryptographic design, then resolve the listed questions about derivation, migration, password handling, and indistinguishability; done requires a defined design and implementation plan for secondary vault behavior.

Written by the indexing model from the issue text.