"synchLock" will become confusing when we have lots of objects with "sync" in the name.

bug#49 Fixed by ensuring that intents for different contacts/groups can be distinguished from each other when resolving PendingIntent refs

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.

- replaced use of Object instance mutex with a private final Lock object
- replaced Object signaling with specific condition signalling

This should make it easier for people to build the project with a freshly
downloaded ADT Bundle.

We don't need two separate executors for long-running IO threads.

Tor has a controller command, TAKEOWNERSHIP, and a configuration option,
__OwningControllerProcess, that work together to ensure Tor shuts down
when the controlling process dies and/or disconnects from the control
port. By using them we can avoid creating runaway Tor processes that
have to be killed with hacks.