Default fork choice value and intermediates for block import parameters

[sorpaas]

Addresses some of #3623.

This PR tries to improve several issues in the consensus engines:

• Currently, if users pass on an incompatible BlockImport with a Verifier, consensus will silently fail.
• Because Verifier does not assume parents, it is not always possible for it to return the correct fork choice rule, but currently it is forced to do so.
• Methods to pipe-line data downwards from Verifier to all subsequent BlockImports is not obvious.

In this PR:

• Changed ForkChoiceStrategy to be Option. If None, it indicates that the BlockImport or Verifier cannot currently make a decision on the fork choice rule. Subsequent BlockImport should properly modify the value. If the value is passed all the way down to the bottom BlockImport, then the block will not be imported.
• Added intermediates in BlockImportParams. This indicates values that should be processed by subsequent BlockImports. If a value in intermediates is not processed, the block import fails. As an example usage of this, in PoW engine, Verifier uses intermediates to pass the calculated difficulty (if available) and the full block hash down to BlockImport, who will then use them to calculate the block auxiliary.
• Updated PoW engine to have proper separation of BlockImport and Verifier.

[rphmeier]

should we not verify the difficulty here in the Verifier, as that's the parallelizable operation?

[sorpaas]

Difficulty may not be parallelizable operation. The mining algorithm is always fixed (or can only be chosen from a set of validated ones), but for difficulty adjustment algorithms, they can be defined in runtime. In those cases, block importer will have to do a runtime call on the parent block to fetch the difficulty. Because parent block may not be available in Verifier, we can only set it to None here, meaning we do not yet know the value.

However, in mining routine, the value of difficulty is indeed available because we mine on local best block. In that case, difficulty is set to Some so we can avoid double calculation.

[rphmeier]

LGTM except for question above

[andresilva]

Changes LGTM. When we want to parallelize the Verifier we might need to make the pipeline more fine-grained though (depending on consensus algorithm). For epoch based consensus protocols we'll only be able to parallelize verification of blocks within the same epoch.

[andresilva]

For babe we might also be able to use intermediates to pass epoch data from verifier to block import (to avoid fetching it twice from the tree). I think this can be done on a follow-up PR though.