Encourage use of different cryptographic secrets for each network

### Givens/Assumptions

- Standard security best practice is to use cryptographic secrets (i.e. cryptographic seeds, seed phrases, and private keys) in such a way as to compartmentalize the risk and impact of their exposure, which in turn allows for the strictness, strength, and cost of the security of these secrets to be tuned based on what information they're meant to protect.
- Compartmentalization of secrets by network is a natural approach to achieve the above which would serve most use use cases well.
- If anything here needs verification, it's this.
- Cryptographic secrets used as "dummy secrets" in certain environments (e.g. development and automated test environments) are very cumbersome to keep secure^[1](#f1).

### Current behavior

Today my only option for network-level compartmentalization is to save my secrets (seed phrases) somewhere outside of MetaMask (I'd recommend 1Password if you're using a digital medium), and then lock/restore from seed phrase every time I want to switch networks.

Enforcing this requires a high level of personal discipline, and even in when such discipline is exercised, accidentally using an account meant for one network on another network is still easier done than avoided.

### Desired behavior

Seed phrases, private keys, and any other secrets should be associated with a particular network, and the UI should discourage reuse between private/trusted and public/untrusted networks by making doing so somewhat burdensome.

### Proposed changes

What follows is an example of how I think this could be achieved, but my purpose in writing it is to illustrate the goal behind this change more so than to perfectly specify these changes. As such, please don't implement this as written without further consideration.

- [ ] On vault creation, when not restoring from seed phrases MetaMask should generate different mnemonics for each network.
- [ ] Accounts added via private key are associated with a specific network and not immediately reusable on multiple networks.
- [ ] When adding custom networks, users are asked whether the network is a trusted (dev/test/local nets) or untrusted^[2](#f2) (testnets, some multi-party private nets, mainnet) environment.
- [ ] When adding custom networks, users are given an option to restore from a seed phrase, or given a newly generated seed phrase if they do not elect this option.
- [ ] When restoring a network with a given seed phrase, or when adding an account to a network via a private key, if the network is indicated to be an untrusted network and if the user is using the same seed phrase/private key as was used in any of their other untrusted networks, a very noticeable but simply worded (language barriers) warning message should pop up telling the user that they should avoid reusing mnemonics between untrusted environments to compartmentalize their losses. This should purposefully be a somewhat jarring experience.
- [ ] Similar to the previous case, in the event that the seed phrase is reused from a trusted environment, the user should be required to type something like "I understand that my ETH might be stolen if I continue" before they can proceed. This should purposefully be an even more jarring experience.

<sub>1. Though ideally these are still randomized to prevent [this sort of thing](https://www.reddit.com/r/ethereum/comments/7z4n6a/people_are_using_the_hardcoded_ganache_seedphrase/). [↩](#a1)
2. The "trusted"/"untrusted" language was the best generic terminology I could come up with on short notice, and I'm not at all wedded to it. I just didn't quite like "Production/Test" or "Production/Development" because some testnets are public and therefore untrusted. [↩](#a2)</sub>

No files, tests, or entry points are named. Start by reviewing the proposed behavior and resolving the security and product scope before locating the affected account, network, and vault flows; done would require an agreed, testable implementation plan rather than the illustrative checklist currently provided.

Written by the indexing model from the issue text.