Refactor API calls to be more robust

[ntoll]

Now that we have several types of API call happening, we should "brainshare" an implementation that neatly meets our requirements now that they are more clear. This should include:

• Addressing the problem identified with API calls that could receive an "empty" object will incorrectly appear as an error` #71.
• Allow for the passing in of a context object (as in current_object) to be used later.
• Allow for the retrieval of the API result from the call (currently self.result).

I suggest the following as a straw man to knock holes in:

• The class emits a call_finished signal with NO value passed. It's just a signal to say the API call is finished (so it's function is similar to the timeout signal).
• The raw result of the API call is in self.result. It's assumed that the handler of the call_finished signal will know what to do with that.
• Any context needed should be passed in as the optional current_object on __init__

This isn't a big change from what we have... in fact I think it simplifies things (fixing #71). However, since all our API calls will go through this (and the associated call_api method on the Client class) then it's important that everyone has an opportunity to kick the tyres before it's implemented (and so we also record the conversation around the design decisions relating to this functionality). Once we get a thumbs up from myself, @redshiftzero and @heartsucker it shouldn't take too long to fix. :-)

[ntoll]

OK... since I'm ploughing through all my GitHub stuff.. I just saw #77 :-) Great minds think alike or fools seldom differ.