KIPs: derive pfReport from a recorded parent round

[hyunsooda]

Specifies how pfReport is derived, to match kaiachain/kaia#1054.

The consensus round is stored in a header byte that is cleared when the block hash is computed, so it is outside a block's identity. A validator locked on a proposal re-votes in every round it reaches, so several rounds can each gather a quorum of committed seals for one block, and two nodes can hold that block, with the same hash, at different rounds. Deriving pfReport from each node's own copy therefore makes the node-state transition node-dependent.

The round of block N-1 is now recorded in header(N).VRank, together with the parent's committed seals as proof that a committee quorum committed it at that round. Every node reads one value, agreed by the quorum that committed block N. Verification proves only that the claimed round happened, never that no higher round did, so a proposer may undercount but cannot inflate — which holds as long as seals are issued only for rounds that actually occurred.

Changes:

• header.VRank becomes a payload with Report, ParentRound and ParentCommittedSeal
• pfReport(N) is redefined to cover block N-1 and to read ParentRound(N), following the index convention cfReport already uses
• New sections for the proposer's writing rule and for the certificate's validation rules
• Epoch starts and FORK_BLOCK record no parent round, with the reasoning for each