Use 2-chain for finality

[arhag]

Other than adapting the tests to work with 2-chain, the only change that should be necessary is to the get_new_block_numbers function in finality_core.cpp.

Switching to 2-chain makes final_on_strong_qc_block_num unnecessary. But for this issue we will keep it for now even though it should always be the same block number as the latest_qc_claim().block_num. So get_new_block_number should always return most_recent_ancestor_with_qc.block_num as the third item in the returned tuple.

The get_new_block_number function likely is simplified to the following (note that the comments have been removed below for brevity but should be adapted in the actual code):

std::tuple<block_num_type, block_num_type, block_num_type> get_new_block_numbers(const finality_core& c, const qc_claim_t& most_recent_ancestor_with_qc)
{
   assert(most_recent_ancestor_with_qc.block_num <= c.current_block_num()); // Satisfied by the precondition.

   assert(c.links.front().source_block_num <= most_recent_ancestor_with_qc.block_num); // Satisfied by invariant 2 of core and the precondition.

   // No changes to last_final_block_num on new claim of weak QC.
   if (!most_recent_ancestor_with_qc.is_strong_qc) {
      return {c.last_final_block_num(), c.links.front().source_block_num, most_recent_ancestor_with_qc.block_num};
   }

   const auto& link1 = c.get_qc_link_from(most_recent_ancestor_with_qc.block_num);

   return {link1.target_block_num, link1.source_block_num, most_recent_ancestor_with_qc.block_num}; 
}

Note that this should also automatically resolve #304 since final_on_strong_qc_block_num cannot go backwards.