Refactor API calls to be more future-proof

_From @theoreticalbts on August 18, 2015 16:21_

Implementation of https://github.com/cryptonomex/graphene/issues/236 has revealed a general issue when extending API calls. When adding parameters to an API call, it has been noted that we should have a cycle of introducing a new call, deprecating the old call, waiting for web UI code to be updated, and then removing the old call.

The deprecation cycle is necessary because adding parameters to an API call breaks every API client that uses that call, even if the new parameters have default values, because the FC reflection API does not understand how to interact with default values due to underlying deficiencies in C++

In this ticket, I propose a solution to this problem: Most or all API calls should be rewritten to take a single `struct`, containing the values that were previously passed as separate arguments. Defaults can then be placed in the C++ `struct` definition, and if some fields do not occur in the JSON dictionary provided by the client, then those fields should not be assigned by the API framework and thus will have their default values.

I should test that the API framework does in fact give fields that do not exist in the JSON object their default values.

_Copied from original issue: cryptonomex/graphene#245_

No source files or tests are named. Start by locating the API framework and representative API calls that currently take separate arguments, then verify whether omitted fields in a JSON object receive C++ struct defaults. Done would require an agreed scope for rewriting calls and confirming that existing clients remain compatible.

Written by the indexing model from the issue text.