thread-safe Gearman client

This interface seems to go against the separation of behavior/data, since its methods expose data (some of it mutable!) as opposed to defining what a Job can *do*.

I think the crux of the matter might be the fact that there are two very different consumers of this right now: the internal logic of the `Client` and users of `Submit`. Maybe the internal logic of the client should be moved here to the `Job` object? Then the `Job` interface could focus on the things that you want after hitting `Submit` on a job: checking/waiting for it to be done, checking its status, listening for data/warnings.

Somewhat unrelated but I think it'd be cool if the Job object internally buffered data and warnings, and the interface returned `io.Reader`s on these. Channel of bytes seems difficult to use.