Factor out -readMutiInfo
Crude use of the regular multi API (non-socket)
Proper scheduling mechanism for multi non-socket working

Should handle multiple transfers at once, with possibly a small delay
getting them onto the queue
Check for errors processing
Suppose we may as well use the CURLMultiLogError macro
I think -processTransferMessages makes a little more sense
Make it clearer whether code is socket-based or not
Ditch pointless -startup call
Shorten wait down to half a second and make clear what we're doing

Means new transfers have to wait at most 0.5s before starting up, which
seems a decent compromise to me
Generate multi errors in the multi handle
Clean up initialisation of timer etc.
Oops, turn socket back off again
Merge pull request #18 from karelia/multi

Use non-socket multi API for async requests