Implement generic API access

[theoreticalbts]

A call for something like steem.get_accounts(["ned"]) currently calls a getattr trampoline which causes the method to be delegated to a method on the Steemd class which is really just a wrapper around the exec method of the HTTP client class, ultimately generating a JSONRPC HTTP request that looks like this:

{"jsonrpc": "2.0", "id": 0, "method": "call", "params": ["database_api", "get_account", ["ned"]]}

In general these wrappers may extend steemd, do some processing of arguments / return value, or even implement entirely new functions not present in steemd itself (for example get_account("ned") is pure Python code which essentially calls get_accounts(["ned"])). But many wrappers, like get_accounts(), are bare exec() calls.

Since Python is a dynamic language, we can implement these wrappers automatically, so for example list_accounts() (a method for which no wrapper exists in Steemd) can be called as:

steem.database_api.list_accounts("ned", 10, "by_name")

All the relevant information is present to create the JSON HTTP request in a convenient syntax.

Note that no wrapper or other specific information about list_accounts appears in any steem-python source file! How does this black magic work? It's simple, you can call anything you please, even nonsense keyboard mashing will work so long as they follow the syntax:

steem.vnnzsld_api.qwerbq("yes", "no", 123456789)
{"jsonrpc": "2.0", "id": 0, "method": "call", "params": ["vnnzsld_api", "qwerbq", ["yes", "no", 123456789]]}

Of course given such a garbage call, the server will return an error which will be raised as an exception in Python. But it shows how the Python code now supports calling literally any method -- it just forwards the call to the server without any checking whatsoever. This is the power of a dynamic language!

But that's not all. The appbase / develop version of steemd supports named fields for all API queries. So it is also now possible to write this call as:

steem.database_api.list_accounts(start="ned", limit=10, order="by_name")
{"jsonrpc": "2.0", "id": 0, "method": "call", "params": ["database_api", "list_accounts", {"start": "ned", "limit": 10, "order": "by_name"}]}

Keyword arguments is an important API upgrade. Now server-side functionality of API calls can be upgraded to accept additional parameters, without breaking backward compatibility with old client code.

This PR implements all of the above functionality.

Support for this keyword argument style of API call is not backwards compatible with legacy (pre-appbase) nodes, but someday soon (HF20?) we will hopefully retire such nodes. User code which needs to speak to legacy nodes can still use the positional argument style or the wrappers in the Steemd class. So this PR shouldn't break any user applications.

[biophil]

This seems incredibly powerful. I've got an open PR to support the delete_comment operation; would yours essentially subsume mine?

[goldibex]

I'm going to approve this because the code is clean and it solves the problem for now; but in general I think we need to avoid this form of metaprogramming, as it makes the code opaque to all but the most experienced readers. I'm on a warpath to rip it out of steem-js, for instance.

[goldibex]

and @biophil this will indeed moot your PR. thanks for bearing with us.