Add deniable profile storage:

storage is fixed since upon initialization. IF there is not file when initializing, one is created with random data
storage is initialized (each time it is used) with blocksize, number of blocks, and number of divisions
each division is assumed to have a password associated with it
divisions should be initialized with a password, so profiles can be loaded, before writing
this mean that if a division is initialized with a different password than previously used, 0 profiles will be loaded, and a new profile will go in slot 0 overwritting what was there
this is a bit of a sucky experience, but any metadata we store starts to degrade deniability
options: 

treat division 0 as more special and store metadata there about how many accounts there are giving the app the ability to tell the user they entered the wrong password for division 0 and allow prevention of overwritting. basically create two types of divisions: deniable and non-deniable
allow client apps to store some potential metadata, like a password hash, so they can tell the user if they entered the password wrong :/ 
?



Add multiple peer support to app and app/cli:

- app now supports multiple peers

- app/cli upgraded to require user to select an active peer for commands

- TODO: fast follow to allow them to do the same for a group and alter group commands to use that instead of argument

app/cli
created two users in one session, peered them, and they had a conversation in a group
testing/tests.sh
testing/quality.sh
testing/ go test