Split watcher logic in three pices:
- Controller: API + message dispatching
- ExpiryWatcher: handle account expirations
- EventHandler: implementation for each handler
This commit allows the account manager to handle the situation where
an account participates in multiple consecutive batches that might still
be in the mempool. Once the first batch confirms, the database state of
the account might differ from the batch key used in that earlier batch.
We need to cancel old spend and conf watches and only watch the latest
batch for confirmation. While an account is in this pending batch state, no
user modification like deposits or withdrawals are allowed so it's safe
to just jump to the latest batch and wait for confirmations on that one.
Otherwise, it's possible for an expiry request to be handled before the
first block notification that sets our best height is received, causing
us to not fulfill the request if the corresponding expiry had already
been reached.
