`get_active_witnesses` and `get_witness_schedule` extended - alternative version

This is an alternative implementation to !730 (closed) (this branch is based on that one, so there are some common changes).

Needs test-tools!99 (merged) and schemas!31 (merged)

Changes affect get_active_witnesses and get_witness_schedule calls in various APIs. The calls have extra boolean parameter include_future that defaults to false (where possible). When called with such value the APIs behave as before the change (unless stated otherwise), with one exception. Call to get_witness_schedule, even with false, returns values taken from future schedule for current_virtual_time and next_shuffle_block_num, since only such values are relevant (values from active schedule are "in the past"). It fixes a bug in the API introduced by HF26.

The following happens when the calls are made with true in parameter.

database_api.get_witness_schedule (actual implementation for other APIs):

• result includes new list future_shuffled_witnesses that is the same as current_shuffled_witnesses, except it is taken from future schedule
• result might include future_changes, but only if there are any changes between active and future schedules. Only the changed fields are elements of future_changes, f.e. if majority_version is different between active and future schedules, but everything else stays the same, future_changes will contain majority_version field with value from future schedule.

database_api.get_active_witnesses (actual implementation for other APIs):

• result includes new list future_witnesses that is the same as witnesses, except it is taken from future schedule

condenser_api.get_witness_schedule:

• same changes as in database_api

condenser_api.get_active_witnesses:

• since routine returns single list, there was only a choice between different bad solutions. The one was selected that keeps old behavior for default parameter, which is to concatenate witnesses and future_witnesses into single list, separated with empty element. Yes, it is no good but other choices were worse. database_api version should be used by callers directly instead.

wallet_bridge_api.get_witness_schedule:

• now requires parameter. Since that API is for wallet, new requirement should be ok. Wallet obviously honors new interface.
• same changes as in database_api

wallet_bridge_api.get_active_witnesses:

• now requires parameter
• same changes as in database_api

wallet_api.get_active_witnesses:

• now requires parameter. Since mechanism used for that API does not handle default parameters, there was no option to have default value.
• the value returned changed from vector to the same as in database_api. It should be ok, since wallet should not be used by scripts, those can call database_api directly from node.

On top of above changes there are two more calls worth mentioning.

debug_node_api.debug_get_witness_schedule:

• it did not change, there is no new parameter, it does not correct values of current_virtual_time and next_shuffle_block_num either (it returns raw value held in state object)

debug_node_api.debug_get_future_witness_schedule:

• new call, returns unchanged raw value of schedule state object, just the one holding future schedule