IF: Consider voting immediately if final on strong qc is validated

Consider voting immediately on a block if its final on strong qc block reference has been validated. The block does not necessarily need to be on our head branch as long as we have validated it.

The voting uncovered a number of problems that are fixed by this PR:

The parent.is_needed() check of best qc in assemble_block was not correctly comparing the qc claim. Add a to_qc_claim to qc to make creating a qc claim from a qc easy.
The fork switch logic for accepted blocks (non-applied blocks) was incorrect. It needed to check pending_head not head.
- Most of the rest of the fixes are because fork switches are now possible as blocks are added to the fork database directly when received after header validation. This means that fork switches can happen much more rapidly as blocks are received. This is true in legacy as well as savanna. As such, this PR can also be thought of as part 2 of #2274.
Existing net_plugin issues uncovered by faster switching enabled by the fork switch fix.
- Use the provided lib of irreversible signal as the fork db is not updated until after the signal is emitted.
- Received blocks that have already been added to the dispatcher block list are applied. Fix the call to sync_recv_block to pass true instead of false. The fast fork switching in tests exposed this issue. The blocks would be added to the fork database and fork switched out before they could be applied.
Numerous fixes to trx_finality_status_forked_test.py. It is very difficult to catch a transaction in the forked-out state as fork switching is happing very rapidly with the fork switching as a result of blocks added to the fork database directly. This is true not just for instant finality but also for legacy consensus.

Also:

Additional debug logging was added to help diagnosis issues.
Renamed proposal_ref to block_ref
Renamed proosal_id to block_id

Resolves #2125

AntelopeIO / leap

IF: Consider voting immediately if final on strong qc is validated #2290