Add extensible whitelist cache to dBFT protocol

[AnnaShaleva]

Rationale

#240 adds extensible payloads verification at the dBFT protocol level for all (both CN and seed) nodes. This functionality covers our current needs, because currently we have the only type of extensible payloads (consensus payloads) and the only type of valid extensible senders (validators). However, in future we may wont to add more extensible types (not likely though) or support more extensible senders (more likely). Thus, we need to make extensible whitelist management more "smart" and add extensible whitelist cache.

Note that this issue is not so critical because we have cache managed by getValidators:

go-ethereum/consensus/dbft/dbft.go

Lines 1643 to 1648 in 47d2712

	if state == nil && blockNum != nil {
	vals, ok := c.validatorsCache.Get(*blockNum)
	if ok {
	return vals, nil
	}
	}

Implementation

It should work similar to NeoGo extensible whitelist management:
https://github.com/nspcc-dev/neo-go/blob/5566e354d451fd14d3b2a856cfe4b1b654a7343e/pkg/core/blockchain.go#L1802

I tried to implement the same approach for NeoX (ref. 96f4a9c, branch https://github.com/bane-labs/go-ethereum/tree/extensible-whitelist), but the tricky part is that this approach works only for CN nodes. Ideally, extensible whitelist should be managed by the blockchian, not by the dBFT engine, and thus it would probably be better to move getValidators call from dBFT to the Eth blockchain API.

[AnnaShaleva]

Depends on #299.