Enforce the bundles contain ER that pointing to the last domain block or extend the head receipt

[NingLin-P]

Add more constraints to the ER to simply the overall design:

• If last_domain_block_number == current_head_receipt, then only ER that points to the last domain block is acceptable
• If last_domain_block_number > current_head_receipt, then the bundle can contain multiple ERs, the first ER must extend the head receipt and these ERs must be consecutive.
• ER that points to domain block > last_domain_block_number is rejected since it is invalid obviously.

With the above changes most of the ReceiptType::NewBranch usage can be eliminated, and with the multiple ER changes #1673 is also fixed.

Estimation: 3-4 days

[NingLin-P]

We also need this constraint to reject invalid bundles that are produced accidentally by honest operators that lag behind the latest domain chain.

Without this constraint, the lagging operator could win the challenge and produce a bundle, but the bundle is validated against the lagging domain chain instead of the latest domain chain, so it may be considered an invalid bundle and cause the operator to get slashed.

With this constraint, the lagging operator's bundle will be rejected (thus no slash) since its ER is not deriving from the latest domain block and doesn't extend the head ER. The constraint will ensure only the operator has progressed its local domain chain to the latest and carries the latest ER in its bundle, which means the bundle is validated against the latest domain chain, and then the bundle will be accepted.

Noted, there is still a race condition that, the operator has build & import the latest domain block, and then it immediately builds and submits the bundle with the tx in its tx pool, before the tx is validated against the latest block (which happens asynchronously in the txpool-notifications worker). Thus we will also need to manually re-validate the tx when constructing the bundle to fix the problem completely.

cc @vedhavyas @ParthDesai @jfrank-summit