datastore: support deferred results. fixes #77.

I thought I'd take a stab at #77. If a response from a `dataset.get` comes back with deferred keys, this will recursively call .get again, only executing the callback passed to the initial .get once, after having gathered all possible results.
Disclaimer: I don't have much experience with javascript.

I think you'll definitely want to have the SDK transparently send followup requests for any keys that were deferred.  As Patrick says, this is what Java and Python do.  Additionally, 99% of Get requests won't have any deferred keys, so I think it would be an unpleasant api if the onus was on the developer to check for this case.

RE: how many subsequent calls would be required/recursive stack depth:

The Datastore backend will defer keys both based on the count of Keys requested and based on the size of the Entities retrieved.  I don't know if we want to talk about the specific limits on this public forum.  It's certainly feasible to craft a pathological dataset of very large Entities that would result in lots of roundtrips.  But that's the whole point of this feature.  It is to move the memory burden off of the Datastore backend and onto the client.

Any reason why you can't do the followup calls iteratively instead of recursively?  Is it just javascript style issues?