* Explain what "account creation" means on first run
* Use hints instead of dedicated text views
* Move password strength meter up into the user's view
* Always move user's view to current input field
* Improve "Forgot Password" dialog

Closes #151

Switched AppBus for ResultHandler, Controller for Helper. Added the basics for LifecycleControllers and implemented it for BriarActivity and NavDrawerActivity

Modified the project structure, removed module extension and went instead for a non-complete core dependency graph

Also removed some unused code from BaseActivity.

* removing screen border visible on small screens
* showing noticeable error message on wrong password input
* showing keyboard again after entering wrong password
* making lost password link easier to recognize as link
* renaming keyboard toggle method from 'hide' to 'toggle'

Also fixed some IME action issues on Android 2.3.

Removed methods that are no longer needed for Java 6, moved the remaining method into the utils directory.

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. :-)