add locks_leader:maybe_become_leader/2

Attempt to resolve Issue #7

1. I haven't been able to reproduce the problem with hanging leader candidates, but It's possible that a leader sets the `leader` attribute to `undefined` in response to a netsplit, and then hopes to get a `have_all_locks` message. However, if the agent has already sent such a message, it won't send it again, unless asked to. However, a `#locks_info{}` message should arrive at any rate. If we are in the `safe_loop()`, we check whether we have the lock, and our `leader` attribute is set to `undefined`. If so, we call `become_leader()`.

2. The crash in `locks_agent:get_locks()` was due to locks being deleted on nodedown, that may have been logged in the `interesting` list. This list is an optimization, keeping track of locks that have a queue of more than one agent (the only ones we need to worry about for dependency analysis). When removing all locks on a certain node, or all instances of a certain object, make sure to also delete them from `interesting`.