Decouple voting from handling finality notifications

[tomusdrw]

Currently the voting code is running only in finalized header notifications. This means the worker needs to observe header and then decide if it votes on that header or not. To make this code work correctly, the candidate selection code most of the time suggests future headers (greater than best_grandpa), and only from time to time we end up with current block. See this PR for more details.

Current implementation, however, is not the best one long-term though. I'd like to propose a change, where candidate selection & voting is decoupled from GRANDPA finality notification handling.

Sketch of the behavior:

1. At any point in time we should figure out what the current candidate is.
2. The candidate has to be between beefy_best & grandpa_best (diff / 2).
3. We periodically vote on the candidate (make sure the votes are gossiped)

The reason for this is that currently, if the node joins the network, it has to wait roughly 2^x blocks before it can start voting if BEEFY is lagging (cause it has to wait for notification that would cause candidate to match best_grandpa). What we want instead is to have the node start voting on what it believes everyone else is voting on as soon as possible. So given one SignedCommitment (best_beefy block) and one finality notification (best_grandpa) it can start voting on some candidate right away.

[andresilva]

This will probably be done in tandem with #102.