Make updating fees and chain_parameters take a single fee / parameter at a time via static_variant

_From @theoreticalbts on February 4, 2016 22:25_

Currently the `committee_member_update_global_parameters_operation` takes a monolithic structure containing all chain parameters and fees. This is incredibly brittle:
- New fees / parameters have to be implemented as extensions. While the `extension` template introduced by cryptonomex/graphene#516 implementation makes this fairly straightforward, it still inevitably involves some amount of awkward boilerplate.
- Unnatural semantics. Usually people want to make a committee proposal of the form "change parameter/fee X and leave all other parameters the same." However this is not possible, you can only have a proposal of the form "set _all_ parameters/fees to these values". Consequences:
- UI's are harder to code (since now you have to essentially implement diffing of these structs in the UI code)
- If a proposal to change fee A to X is created, then another proposal to change fee B to Y is created, then the committee cannot approve both proposals; whichever proposal goes through last will undo the other proposal! Worse, a UI which only shows diffs actually implies diff semantics, so if the UI shows that the first proposal will change A to X and the second proposal will change B to Y, it is very counter-intuitive that A will be changed _back_ to its previous value by the second proposal!
- FBA requires some fees to be settable by someone other than the committee. It is hard to write code to inspect the current data structures to determine who has permission to do a particular fee update.

Here is a plan for a migration which can address these shortcomings:
- Rename `fee_parameters` to `fee_parameter`.
- `blockchain_fee_update_operation` takes a `fee_parameter` object which is a `static_variant` of all possible fee types.
- Replace each chain parameter with a single-member `struct`.
- `blockchain_parameter_update_operation` takes a `chain_parameter` object which is a `static_variant` of all such `struct`
- The current serialized versions of `fee_schedule` and `chain_parameters` are put into a new `include/graphene/chain/protocol/legacy` directory and `graphene::chain::protocol::legacy` namespace
- New versions of `fee_schedule` and `chain_parameters` go into `include/graphene/chain` which can be updated with new fields without changing serialization; new code containing new fees / parameters will consider them to already exist and have their default values, they will merely be immutable until the hardfork date passes (i.e. `blockchain_fee_update_operation` / `blockchain_parameter_update_operation` targeting new fee/parameter values should fail evaluation until the hardfork date arrives; by the hardfork date, most witnesses will have upgraded and will understand the new `static_variant` members when they appear on the wire)
- The GPO will still be a monolithic object that includes all fees and parameters, wallets shouldn't have to change their fee determination code as long as they ignore unknown keys in the JSON

_Copied from original issue: cryptonomex/graphene#554_