1. The things we're really trying to protect - contact identities,
message contents, etc - can't be erased from memory because they're
encapsulated inside objects we don't control.

2. Long-term secrets can't be protected by erasing them from memory
because they're stored in the database and the database key has to be
held in memory whenever the app's running.

3. If the runtime uses a compacting garbage collector then we have no
way to ensure an object is erased from memory.

4. Trying to erase secrets from memory makes the code more complex.

Conclusion: Let's not try to protect secrets from an attacker who can
read arbitrary memory locations.

Thanks to the team that audited CryptoCat for this idea. :-)

If the schema of the database is incompatible with the schema expected
by the code, the database throws a DbSchemaException. LifecycleManager
indicates the error to BriarService, which uses HomeScreenActivity to
show a notification and quit the app.

Private messages are now the same as group messages, but groups can be
private or public. When a contact is added, a private group is created
and designated as the inbox for exchanging private messages with the
contact.

Fixes issue #3611920, but keep the issue open because more activities
will be added.

Android doesn't currently store bundles persistently, so it's premature
to protect against accidental information leaks through persistent
bundle storage. Protecting against deliberate information leaks by the
OS is probably futile, so there's currently no need for bundle
encryption.