T1737
Cashtab switched from keeping distinct state parameters in state to keeping all state parameters in an object called `wallet.state`. This was done to dramatically speed up loading times by loading cached wallet state from local storage instead of polling the API every time the app opened.
Because this was done with active users with wallets that did not have this state parameter, some kind of migration system had to be devised. This was rolled out incrementally as some screens did not exist until after the migration (Tokens.js).
This diff standardizes how the newer `wallet.state` parameters are used.
1) Screens are simply not rendered until an unmigrated wallet has migrated (at this point, very unlikely anyone would have an unmigrated wallet)
2) This simplifies and standardizes validation checks across the `Send.js`, `SendToken.js`, `Tokens.js`, and `Wallet.js` screens
3) Because wallet is temporarily not valid while the state is updating, `previousWallet` is used as a rendering fallback (without this, the app will flash a 'create new wallet' screen while updating state
Some unit tests were removed because this diff changes how an invalid wallet is handled. Previously, rendering for invalid wallets was handled on a screen by screen basis. Now, the app will lock with a spinner until a valid wallet is loaded.
This refactor is necessary to prevent 2 sources of truth for wallet state. Another diff is still necessary to completely remove use of legacy wallet state parameters (they are still used for incoming transaction notifications).