Client set hosts

Three changes, the first required by the third.

Strip out odd usage of itertools in Connection
------------------------------------------------------------------------------

From what I could tell `itertools.cycle` was being used so that connection could iterate over the client hosts indefinitely, but then it was still stopping after every full rotation so that an outer retry could do its thing.  I did away with that behavior and just used a for loop in the outer scope.

Get rid of the HostIterator and RandomHostIterator objects
------------------------------------------------------------------------------

HostIterator in particular was kind of silly, since list iterators are safe to iterate over while their underlying list is being modified and the only thing HostIterator was doing was (half) implementing the iterator contract with a copy of the stored list.  It seemed like HostIterator may have originally been meant to protect against somebody modifying `hosts`, but this in combination with `itertools.cycle` meant that even if somebody _did_ change hosts then the connection instance wouldn't be changed in any way.  In short, I don't think HostIterator or RandomHostIterator were providing any value at all so I think they should be removed.

Technically this means that the host list is not randomized each time somebody iterates over it, but with the `cycle` I removed in the previous commit it would have the same behavior as at the end of this change anyway, so I don't think that behavior was being used or relied upon in any way.

Provide an official way to grow/shrink the list of zookeeper endpoints
------------------------------------------------------------------------------

I've been doing this via a session listener and punching in an arbitrary `hosts` into my 1.0 clients in response to disconnection events for months now and it's been working great.  However this behavior is broken in 1.4 so I'd like to make the behavior builtin.

Basically, if you're connected it has no effect until you become disconnected, and if you're disconnected then the next time it runs through the list of hosts your new list gets used.  This is super handy if you have clients you don't want to stop/start but the list of zookeeper endpoints is growing or generally in flux. 

I don't use chroots in any of my code so I opted to leave changing the chroot in a running client as an explicit error.  I'm not entirely sure how that use case would even flow but I'm sure somebody else could do it pretty easily if they thought it would make their life easier.