Better fork-choice APIs

re: https://github.com/paritytech/polkadot-sdk/issues/875

Block-based updates to fork-choice

The BlockImport implementations of consensus engines currently have the option to determine the "fork choice strategy" for a new block B. But the fork choice strategy options are limited: when importing a new block, we have 2 options:

1. Longest chain fork-choice rule. Basically, we choose to defer to the client/db to figure out if this is the best block based on if it represents the longest chain
2. "Custom" fork-choice rule. This gives the consensus engine the right to tell the client/db directly whether the new block is the best or if it's not.

The issue with "Custom" is that it is only exposing two possibilities: the possibility that the new block is the best block, and the possibility that the current best block is still the best block. It doesn't expose the possibility that the new block is not the best block, but also that the best block has changed to some other block entirely.

fork-choice updates between blocks

Our APIs also currently assume that fork-choice can only change based on new blocks. There may be other factors in more complex systems: the passage of time, or the receipt of new messages on the network.