Draft: add queen-mode to witness plugin

Witness plugin in queen mode is a tool for preparing block logs with blocks (particularly the bigger ones) filled as much as possible (or up to desired size). While it is possible to prepare such block logs on sufficiently powerful server with regular script that uses APIs, the idea behind queen mode is to allow to do that on regular machine. Moreover, if the machine has sufficient power, it is possible to produce blocks significantly faster than it would normally take. It enables preparation of large block logs to be used for further testing with replay or live mode through use of pacemaker (or mock-peer in the future).

Initially it was supposed to be separate plugin, however it turned out that almost everything is the same as in witness plugin, therefore it was made as (testnet only) option for existing plugin.

While it might work in different configurations its intended use is the following:

• use one testnet node
• configure API and/or plugin that will be used to receive / generate transactions
• add plugin = witness to config.ini
• add all witnesses you plan to use in your block log as well as their signing keys with witness and private-key settings respectively
• add queen-mode = 0 for max size blocks (as selected through witness properties) or queen-mode = <size> for desired size of blocks (they will still be smaller in case witnesses voted for blocks smaller than given <size>)
• use configured state (use one of prebuilt block logs for replay or a snapshot that already has voted in witnesses, desired size of blocks set, stable vest/rc price and accounts created); remember to use alternate-chain-spec compatible with your chosen block log / snapshot
• start the node - witness will wait for incoming transactions until they fill up the block; the first transaction that would fill up the block or go over limit will trigger block production
• use any means of producing transactions and passing it to the node; for big blocks, slow computer or simply because rate of incoming transactions is slow, it is more likely that the node will have to wait for incoming transactions - this is normal; if you are using colony plugin for generating transactions, the best is to use unrestricted rate, otherwise it might produce too few transactions to fill the block and the process will stop (queen will wait for more transactions to produce block, while colony will wait for block to reset its transaction counters)
• you can force block production with use of debug_node_api.debug_generate_blocks (but don't use edit_if_needed - it might prevent resulting block log from being viable for replay due to required use of skip flags)
• when finishing production of block log either force production of last block (preferred), or add one block worth of some filler transactions - if you don't do that, there will be some transactions you'd want in block log that will remain in the node as pending and never reach the block

The step above - use of configured state - can be replaced with sending transactions normally and forcing block production (similarly to what happens in witness_tests/queen_mode_test added in this MR), but it is just much more convenient to use block log or snapshot prepared in advance.